Laden...

Ist Mono geeignet für Sandbox Spiele wie Minecraft?

Erstellt von burli70 vor 6 Jahren Letzter Beitrag vor 6 Jahren 5.687 Views
B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren
Ist Mono geeignet für Sandbox Spiele wie Minecraft?

Ich möchte ein eigenes Sandbox Spiel programmieren und ich frage mich, ob Mono eine gute Wahl dafür ist.

Minecraft ist in Java geschrieben und hat so seine Performance Probleme in manchen Bereichen. Da Mono vom Grundprinzip vergleichbar ist frage ich mich, ob sich nicht die gleichen Probleme ergeben.

Grundsätzlich müsste man so ein Spiel in C++ schreiben, aber konnte mich mit der Sprache noch nie anfreunden. Und Rust ist noch zu neu.

Kann man so ein Spiel in Mono entwickeln ohne in eine Performance Falle zu tappen oder wäre C++ oder Rust die bessere Wahl?

Gruß,
Markus

5.657 Beiträge seit 2006
vor 6 Jahren

Hi burli70,

klingt für mich eher nach einem Anwendungsfall für Unity 3D, oder willst du die ganze 3D-Darstellung selbst entwickeln?

Ansonsten gibt es noch andere Alternativen: [FAQ] Wie finde ich den Einstieg in die 3D-Programmierung mit C#?

Weeks of programming can save you hours of planning

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich bin noch unschlüssig. Unity ist schon nicht verkehrt, aber ich würde das Spiel gern komplett OpenSource machen. Lieber wäre mir eine Game Engine mit OpenGL oder noch besser gleich Vulkan Support. Ganz von 0 möchte ich nicht anfangen.

Die generelle Frage ist, ob es Sinn macht, Mono überhaupt dafür zu verwenden. Mit Mono 5.0 gibt es ja eine neue Garbage Collection, die da vielleicht helfen würde.

3.003 Beiträge seit 2006
vor 6 Jahren

Die Performanceprobleme von Minecraft direkt auf Java zu schieben, halte ich für ziemlich naiv. Die gewählte Programmiersprache ist der letzte Schuldige.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

So wie ich das verstanden habe verursacht der Garbage Collector die Probleme. Wenn der läuft steht der Rest. Dadurch können Ruckler enstehen. Das soll erst mit dem neuen Concurrent Garbage Collector von Mono 5.0 besser sein.

3.003 Beiträge seit 2006
vor 6 Jahren

Darf man fragen, wo du das her hast? Ich halte das für eine ziemlich abenteuerliche Behauptung.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.806 Beiträge seit 2008
vor 6 Jahren

Es ist schon wahr, dass der "background collector" ein Stop-The-World Collector darstellt.
Alle Threads werden dabei gestoppt, dann wird gecleaned, und dann die Threads wieder "gestartet".
Beim Concurrent Collector wird nur ein Teil des Heaps gelockt, sodass es hier Stop-The-World Symptome nicht auftreten.

Dass aber Java grundsätzlich hier unperformant ist: absolut abenteuerliche Behauptung.

T
2.219 Beiträge seit 2008
vor 6 Jahren

Ich kann hier auch in Richtung Unity 3D eine Empfehlung abgeben.
Da hast du die Engine schon komplett fertig.
Dann musst du dich nur noch um den Content(Assets wie Audio, Models und Texturen) sowie deine Skripte für die Spiellogik kümmern.

Die Performance von Java ist hier kein Problem, hab mit Java auch schon einige Jahre Erfahrung.
Hier gibt es auch in Java 9 schon Bestrebungen den GC auf den G1 umzustellen, der dann mit geringen Pausen daher kommt.
Bisher hatte ich mit dem Default GC aber nur dann hohe Pausen wenn ich wirklich unzählige Objekte hatte und den Speicher uch stark begrenzt hatte.
So musste der GC Zwangsweise mehrfach pro Sekunden die Anwendung stoppen und arbeiten.
Dies ist aber ein reiner Sonderfall den man bei Java nur bei schlechter Konfiguriation der Startparameter hinbekommt!

Das Problem von Minecraft ist eher die dynamik und die größe der Karte.
Je nachdem wie der Code von Minecraft aussieht, kann es bei zu vielen Objekten in direkter Nähe Performance Probleme geben.
Teilweise liegt es aber auch an der Hardware die man für Minecraft benötigt.
Auch wenn die Grafik mit seinen Pixel Blöcken nach Low Budget aussieht, ist hier gerade die CPU der Knackpunkt.
Dies wird aber auch bei den Optionen angezeigt, wenn man z.B. die Weitsicht auf den höchsten Wert setzt.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

S
248 Beiträge seit 2008
vor 6 Jahren

Die Frage ist wie lange der GC die Anwendung anhalten kann, ohne dass es den Benutzer stört. Dies hängt natürlich von mehreren Faktoren ab: Runtime, GC Konfiguration, Größe der Anwendung, erwartete Framerate, ...

Wenn du dieses Risiko nicht eingehen willst, dann müsstest du direkt eine Umgebung ohne GC verwenden.
Dabei solltest du bedenken, dass die GC-Zeiten wachsen werden, wenn deine Anwendung wächst. D.h. dies kann sich erst im Laufe der (Weiter)Entwicklung bemerkbar machen.

Hier ein Artikel der dir möglichweise weiterhilft:
Fundamentals of Garbage Collection

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich habe jetzt keine konkrete Quelle, ist aber das, was immer behauptet wird.

Für Mono hab ich das hier gefunden

http://www.mono-project.com/news/2017/05/17/concurrent-gc-news/

Selbst mit dem CGC scheint es noch Pausen zu geben, aber eben nicht mehr diese extrem langen.

Deshalb habe ich ja Bedenken vor dem Einsatz von Mono und hätte gern mal eine Meinung dazu. Ich denke nämlich, dass bei so einem Spiel der GC recht häufig aktiv werden muss, weil ja immer die Map Daten um einen Spieler herum in den Speicher geladen werden müssen und wenn der Spieler einen Bereich verlässt werden die Daten wieder freigegeben. Die muss dann der GC beseitigen. Tut er das nicht ist der Speicher irgendwann voll. Ich vermute, deshalb wird bei Minecraft immer empfohlen, Java mehr Speicher zuzuweisen.

Ich weiß nicht, wie der Java GC arbeitet und ob der auch alle Threads stoppt, aber in Anbetracht der Datenmenge und der "Symptome" klingt es zumindest plausibel.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Die Arbeitsweise von Voxelgames ist mir durchaus geläufig. Ich habe einige Erfahrung mit einem ähnlichen Spiel. Deshalb habe ich ja die Befürchtung, dass Mono vielleicht nicht ganz das richtige sein könnte

Die Größe der Map ist nicht das Problem. Es wird immer nur ein gewisser Teil der Map rund um einen Spieler in den Speicher geladen. Das muss aber auch immer wieder freigegeben werden. Je mehr Spieler in unterschiedlichen Regionen, umso mehr Daten müssen geladen und wieder freigegeben werden.

Ich vermute, dass da auch bei Minecraft der Knackpunkt ist, von Problemen wie Unmengen Entities mal abgesehen.

Da Mono 5.0 noch neu ist glaube ich auch kaum, dass schon jemand mit nennenswerten Erfahrungen aufwarten kann.

3.003 Beiträge seit 2006
vor 6 Jahren

Garbage Collection ist eben nicht trivial. Wenn man in den Bereich kommt, wo man den GC tunen muss, wird es haarig. Dafür merkt man dann aber auch den Unterschied zwischen Entwicklern und Fricklern. Minecraft als Beleg für schlechte Java-Performance heranzuziehen ist genau so fair,, als würde ich BER als Beleg dafür nehmen, dass Deutschland die guten Ingenieure ausgehen. Beides Quatsch.

http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich gebe ja nicht Java an sich die Schuld. Ich denke, dass es das generelle Konzept des GC ist, was da Probleme macht

Nochmal zu Unity: Ich glaube, dass Unity für mein Vorhaben die falschen Grundlagen bietet. Ich kann bei dem Spiel Assets usw gar nicht nutzen. Ich müsste Unity als reine Grafikengine nutzen. Außerdem soll es komplett Open Source sein.

Xenco scheint es nicht für Linux zu geben, die Delta Engine ist seit 3 Jahren nicht mehr weiter entwickelt worden, die Wave Engine ist wohl nicht Open Source.

Was mir vorschwebt ist was in Richtung Irrlicht, OGRE oder so ähnlich, aber das ist Thema für einen anderen Thread

W
955 Beiträge seit 2010
vor 6 Jahren

Aber was sollen wir dir denn jetzt sagen? Wir wissen es nicht welche konkreten Anforderungen du hast. Also musst du entweder selber einen Prototypen bauen oder gleich auf eine andere Programmierumgebung ausweichen, vllt C++ mit eigenen Mem-Allokatoren.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Schwer zusammen zu fassen. Das Spiel besteht aus einem Server und einem Client, die unabhängig voneinander laufen. Der Server generiert die Karte und speichert sie in einer Datenbank. Auf Anforderung stellt er sie blockweise dem Client zur Verfügung.

Im Wesentlichen geht es um die Verwaltung dieser Blöcke. Die werden immer nur so lang benötigt bis sie den Radius eines Spielers verlassen. Dann können sie gelöscht werden. Wenn sich jetzt mehrere Spieler an verschiedenen Orten bewegen kommt da eine Menge an Blöcken zusammen, vor allem auf dem Server. Dementsprechend stark kann der Speicher fragmentiert werden.

Die Frage ist, ob man verhindern kann, dass das Spiel alle paar Minuten oder sogar alle paar Sekunden für mehrere 100ms stehen bleibt. Der neue GC scheint wohl selten länger als 100ms zu blockieren, aber selbst 100ms können schon stören, besonders am Client würde das auffallen

D
985 Beiträge seit 2014
vor 6 Jahren

Dann implementiert man einen Pool, wo alle nicht mehr verwendeten Block-Instanzen weiter vorgehalten werden bis man wieder eine Block-Instanz benötigt.

Wird der Pool irgendwann zu groß, dann kann man die immer noch rauswerfen - daran würde ich mich aber erst zum Schluß begeben oder wenn der Speicher ausgeht.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Also so lang im Speicher halten wie möglich. Muss ich mir mal Gedanken machen

D
985 Beiträge seit 2014
vor 6 Jahren

Ja, denn wenn man sich bewegt fliegen hinten Blöcke raus und vorne werden welche benötigt. Ist dann quasi ein Kreislauf.

Wenn ein Berg kommt braucht man mehr und wenn man den Berg verlässt, dann sind halt viele Blöcke im Pool, die man aber wieder braucht, wenn der nächste Berg kommt (oder sich umdreht und wieder zum Berg zurückkehrt)

16.806 Beiträge seit 2008
vor 6 Jahren

Vor allem kostet Zeugs aus dem Speicher werfen ebenfalls Zeit und Ressourcen.
Daher ist der GC auch so konzipiert, dass er dies in seiner "freien Zeit" oder wenn unbedingt notwendig macht, und nicht dauernd.

Da Mono 5.0 noch neu ist glaube ich auch kaum, dass schon jemand mit nennenswerten Erfahrungen aufwarten kann.

In der Open Source Welt, wie sie Mono ist, hat jeder die Möglichkeit schon vor einer Release Version Erfahrungen zu sammeln.
Und natürlich gibt es diese hier schon. Mono selbst ist aber keine komplette Neuentwicklung, sodass frühere Erfahrungen deswegen nicht gleich obsolete sind.

Für mich hört sich an, dass Du konzeptionelle Architektur-Fehler hast, die Du auf Mono/den GC schiebst.

PS @ burli70: bitte keine Full-Quotes.
Siehe auch [Hinweis] Wie poste ich richtig?
Wir Mods haben auch anderes zutun, als Deine Full quotes dauernd zu entfernen.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Für mich hört sich an, dass Du konzeptionelle Architektur-Fehler hast, die Du auf Mono/den GC schiebst.

Nein, ich versuche nur Informationen zu sammeln, um Fehler möglichst zu vermeiden

16.806 Beiträge seit 2008
vor 6 Jahren

Auch mit einem Nein kannst Du mein Eindruck nicht verneinen.
Du hast Thesen, die Dich zu Aktionen und Aussagen verleiten.

Eine Frage wie "wie verhindere ich XY, wie gehe ich optimal vor, was sind best practises" ist doch viel hilfreicher als "ich nehme X an, daher mache ich Y. Ok?".
Deine Grundfrage, ob Mono geeignet ist, hat ja schon die These in sich, dass Du offensichtlich den Eindruck hast, dass dem eben nicht so ist. Du gehst ja auch schon direkt drauf ein, dass man so ein Spiel in C++ machen müsste; ich wüsste nicht wieso.
Schau Dir doch allein die official gallery von Unity an. Dort sind Spiele, die sind wesentlich aufwändiger als Minecraft zu sehen...

Es ist nur ein Tipp meinerseits, dass Du evtl. eine andere Herangehensweise annimmst, um die Lösung eines Problems zu finden.
Weil so wird das - siehste ja selbst - in Diskussionen ausarten, die unnötig sind und Dich selbst auch nicht voran bringt.

Nicht umsonst gibt es hier im Thread ja schon nachfragen wie Aber was sollen wir dir denn jetzt sagen?

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich fange einfach mal an

S
248 Beiträge seit 2008
vor 6 Jahren
B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Zusammengefasst: wenn der GC zu stark bremst kann ich immer noch unsafe gehen

3.003 Beiträge seit 2006
vor 6 Jahren

Nochmal: nicht der GC ist schuld an schlechter Performance, der Entwickler ist es. Das scheint irgendwie nicht bei dir anzukommen. Das Konzept der Garbage collection ist nicht per se unperformant. Unreal engine, Unity 3D, cry engine (in Teilen)...benutzen alle garbage collection. "Wenn's an der Performance hapert, benutz ich halt unsafe"...oje.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

16.806 Beiträge seit 2008
vor 6 Jahren

Bei der Aussage burli70, tuts mir nicht um Dich leid, sondern mir tut es leid, dass Du etwas völlig ohne Grund die Schuld zuschiebst und das in die Welt und möglicherweise in den Bekanntenkreis trägst.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ihr habt mich falsch verstanden. Ihr habt doch selbst gesagt, dass der GC das komplette Programm stoppen kann. Und eine Möglichkeit ist es, den Speicher ohne GC selbst zu verwalten.

Ich habe nicht mehr sagen wollen als "wenn es mit dem GC wirklich aus irgendwelchen Gründen nicht mehr geht kann ich die Daten unsafe speichern"

@LaTino: hast du den Code von Unity gesehen oder woher weißt du das? Vielleicht managen sie die Daten ja auch selbst ohne GC. Oder hast du eine Quelle für deine Aussage?

D
985 Beiträge seit 2014
vor 6 Jahren

@LaTino: hast du den Code von Unity gesehen oder woher weißt du das? Vielleicht managen sie die Daten ja auch selbst ohne GC. Oder hast du eine Quelle für deine Aussage?

Interessierte können es einfach in der Dokumentation nachlesen. Es gibt sogar Tutorials direkt bei Unity3D, die sich explizit mit dem GC und der Optimierung bzgl. dessen beschäftigen.

Wenn du ernsthaft programmieren möchtest, dann sollte der Blick in die Doku/Tutorials zum Reflex werden.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Die Unity Dokumentation ist nicht unbedingt die erste Anlaufstelle an die ich denke, wenn ich C# lernen will, auch wenn sich ein Blick vielleicht lohnt.

Und eine Erklärung des GC in der Doku ist kein Beleg dafür, dass Unity intern ausschließlich managed Code verwendet. Die Doku bezieht sich, so weit ich das bisher gesehen habe, auf das Scripting in C#. Sollte ich was übersehen haben könnte es daran liegen, dass ich zur Zeit nur mit einem Handy und 64k Bandbreite ins Internet komme. Also verzeiht mir, wenn ich da gerade nicht so schnell bin.

Nochmal: der GC kann trotz aller Optimierungen zu einem Problem in einem Spiel werden. SOLLTE das der Fall sein kann man den GC einfach umgehen und die problematischen Daten einfach selbst speichern und verwalten. Richtig oder falsch?

Und jetzt beruhigen wir uns alle wieder und diskutieren normal weiter

T
2.219 Beiträge seit 2008
vor 6 Jahren

@burli70
Mit unsafe kannst du deine "Daten" selbst Verwalten.
Aber wie eben schon alle sagen, ebenfalls auch mein letzter Post, gibt es nur sehr sehr selten Fälle in denen man sowas braucht/machen muss.
Der GC ist auch schon soweit in C# optimiert, dass es selbst in Spielen nur dann zu einem Problem kommen kann, wenn man schon falsch programmiert.
Damit der GC dauerhaft zum Problem wird, müsstest du z.B. unmengen an Objekten erzeugen.

Gutes Beispiel dafür wäre mit eingie Threads große Byte Arrays anzulegen in einer schleife und dann dem GC beim collecten zu sehen.
Aber wie schon mehrfach von Abt und Sir Rufo erwähnt, liegt es dann am Code nicht an C#/.Net etc.

Alle die dir hier antworten, haben schon Jahre lang Erfahrungen mit C# und verdienen auch ihr Geld damit, mich mit eingeschlossen.
Wenn Sie dir sagen, dass unsafe hier Unsinn ist und du dem GC vertrauen kannst, dann hat dies auch schon Jahre an Erfahrung als Grundlage.

Unsafe ist auch der falsche Ansatz für Spieleprogrammierung und wird auch nur in Fällen benötigt, in denen der GC eben nicht eingreifen darf.
Dies sind aber Fälle, die selbst in der Spieleprogrammierung sehr selten sind.

Wenn du dem GC nicht vertraust, was an deinen Posts abgeleitet werden kann, dann bist du bei C#/.Net an der falschen Adresse.

Auf Platformen wie Steam und co. tummeln sich sogar seit Jahren Spielen, die in C#/.Net entwickelt wurden.
Dort kannst du dich an die entsprechenden Entwickler wenden ob diese unsafe o.ä. benötigen.
Meistens wird dies aber nicht der Fall sein, da dort entweder Xna oder Wrapper für populäre Libraries wie SDL/SDML zum Einsatz kommen.
Diese werden dann mit P/Invoke auf die eigentlichen Libs gemappt und können dann selbst die Handles ohne unsafe durch Disposen freigeben lassen.

Man kann in C# die meisten Sachen ohne unsafe in reinem Manged Code schreiben.
Nur wenn es sehr Platformnah, also eben über Zeiger laufen muss, dann braucht man unsafe.
Ansonsten kannst du alles ohne große Probleme mit C# in Manged Code machen.
Der GC ist hier immer dein Freund, wenn er mal mehr machen muss als gedacht, dann musst du deinen Code prüfen.
Nicht selten erstellt man mal in Schleifen immer wieder benötigte Objekte von großen Klassen, die dann wieder weg geräumt werden müssen.

Nachtrag:
Sir Rufo bezog sich eigentlich nicht nur auf die Unity Dok sondern generell sollte man die Dokus lesen.
Guter Anfang wäre z.B. für dich auch mal die MSDN Dokus zu .Net zu lesen.
Das Thema unsafe sollte dir auch klar machen, dass dies nur dann benötigt wird, wenn du mit Zeigern und Unmanged Resourcen arbeiten musst.

Nachtrag 2:
Zum Thema GC Pausen.
In der Regel dauern diese nur wenige Millisekunden oder bei gutem Code, gibt es sogar über einen längeren Zeitraum mal keine.
In der Regel sollten die Pausen auch nur in Millisekunden Bereich liegen.
Schon ab rund 100ms sind die Pausen für schnelle Spiele wie Shooter zu lang.
Aber hier schreitet der GC auch nur ein, wenn du massiv Daten erstellst und verwirft.

Gerade beim Thema GC solltest du dir am besten mal ein einfaches Konsolen Programm bauen und schauen wie sich der GC verhält und was du machen musst um diese länger collecten zu lassen.
Ich denke heir musst du einfach deine eigenen Erfahrungen sammeln, dann siehst du auch wie der GC arbeitet und ob er den wirklich so böse ist, wie du denkst 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich glaube euch das alles, aber ich habe einige Erfahrung mit Voxel Games wie Minecraft und weiß, was da für Datenmengen anfallen, egal wie gut man programmiert. Die Spiele sind, verglichen mit zB Egoshootern, sehr Speicher- und CPU-lastig. Nicht umsonst werden die Daten in einer Datenbank gespeichert, weil nicht alles in den Speicher passt.

Ich bin vielleicht noch kein guter C# Programmierer, aber mit Voxel Games kenne ich mich gut aus. Wenn zB Client und Server auf einem PC laufen für ein Singelplayer Game und der Rechner vielleicht nur 4GB hat, dann könnt ihr mir glauben, dass der Speicher schnell voll ist, wenn ihr nicht gerade auf der Stelle stehen bleibt.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@burli70
Mich würde interessieren welche Datenbank du hier nimmst.
Auch wäre dann die Frage wie deine Datenstruktur aussieht, dass du eine Datenbank brauchst.
Mir ist kein Spiel bekannt, dass wegen zu großer Datenmengen eine lokale Datenbank braucht um alle Daten zu merken.

Hier klingt es eher so, als wären deine Datenstrukturen zu groß bzw. dein Code nicht optimal.
Wenn dein Spiel Daten in einer DB speichern muss, klingt dies eher nach einem falschen Ansatz.

Hier muss dein Spiel nicht sichtbare Daten ausblenden(clipping) und die Datenstrukturen auf ein minimum begrenz sein.
Auch musst du schauen ob deine Datentypen nicht für ihren Zweck zu groß sind.
Faustregeln wie float anstelle double zu nutzen, sollten dabei immer beachtet werden.
Es gibt kaum Fälle in denen man mehr als float nutzen sollte.
Wenn möglich sollte man sogar auf float verzichten und int nehmen, damit kann die CPU am schnellsten arbeiten und der Speicherverbrauch ist identisch

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Das hat nichts mit "meinem" Spiel zu tun sondern mit der Natur von Sandbox Games.

Die Welt besteht aus Würfeln von 111m Größe und für jeden Würfel muss man eine Gewisse Menge an Daten speichern, zB um welchen Würfel es sich handelt, ob er rotiert ist, welcher Lichtlevel an dieser Position ist usw. Dazu können für jeden individuellen Würfel auch noch eine ganze Menge Metadaten dazu kommen. Ist ein Würfel zB eine Kiste wird das Inventar der Kiste in den Metadaten gespeichert.

Die gesamte Welt wird mit Noise Funktionen (meistens Perlin Noise) procedural generiert und muss irgendwo gespeichert werden. Zur Laufzeit werden benötigte Daten permanent aus der Datenbank geholt oder, falls noch nicht geschehen, neu generiert.

Sandbox Games haben keine vorgegebene Welt oder Level. Wenn man eine neue Karte erstellt wird die Welt jedes mal neu generiert.

Natürlich wird die Welt nicht komplett im Speicher gehalten. Es wird immer nur ein Bereich um einen Spieler im Speicher gehalten. Minecraft organisiert die Welt in sogenannten Chunks. Jeder Chunk besteht aus 1625616 Blöcken. Wenn man eine Sichtweite von 10 Chunks einstellt muss sowohl der Client als auch der Server die Daten für 2621440 Blöcke im Speicher halten, wenn ich mich nicht verrechnet habe. Wenn man jetzt noch berücksichtigt, dass jeder Block mehr als ein Byte braucht kommt da schon ein bissel was zusammen.

Und das gilt jetzt nur für EINEN Spieler der sich nicht bewegt. Ein Server mit 50 Spielern hat eine ganz schöne Datenmenge zu verarbeiten, wenn sich die Spieler nicht gerade nahe beieinander befinden.

Man kann die Datenbank jetzt natürlich in komprimierter Form speichern, aber im Ram wird es normalerweise nicht komprimiert.

Nur damit ihr eine Vorstellung von der Größe einer Minecraft Welt bekommt: eine Karte kann aus 60.000.00060.000.000256 Blöcken bestehen. Selbst wenn für jeden Block nur 2 Byte gespeichert werden müssten gibt es glaube ich keinen Computer auf der Welt, der eine komplette Karte im Arbeitsspeicher halten kann. Nur mal um euch zu verdeutlichen, von welchen (theoretischen) Datenmengen wir hier sprechen.

Und vielleicht könnt ihr meine Bedenken hinsichtlich des GC jetzt etwas besser verstehen. Es ist egal, wie sehr man das optimiert, man muss bei diesen Spielen mit großen Datenmengen arbeiten, die man nicht einfach wegoptimieren kann. Irgendwann ist der Speicher einfach voll und der GC muss aufräumen, was bedeutet, dass das Spiel für einige ms angehalten wird.

Eine Pause auf der Server Seite kann man da sogar noch abfangen, weil man durch die Netzwerk Latenz eh mit Prediction usw arbeiten muss, aber auf der Client Seite kann das ein Problem werden.

Man kann Voxel Games nicht mit anderen Spielen vergleichen, die üblicherweise zB mit Unity erstellt werden. Das ist eine völlig eigene Klasse von Spielen

16.806 Beiträge seit 2008
vor 6 Jahren

Ich glaube euch das alles, aber ich habe einige Erfahrung mit Voxel Games wie Minecraft und weiß, was da für Datenmengen anfallen, egal wie gut man programmiert.

Es hängt viel weniger mit der Programmierung als mit der Architektur zusammen.
Und so wie man Deine anderen Threads auch so liest, liegt Dein Problem sicherlich nicht im GC oder im Framework, sondern viel mehr am Umgang dessen.

Dein Beschreibung ist auch nicht exklusiv für Sandbox Games.
Das trifft auf sehr viele Anwendungen zu, zB. Games, CADCAM... all das hat hinter Elementen, egal ob Würfel oder nicht, viele Daten.

Ich halte mich nun hier raus, weil es nichts bringt. Du bist irgendwie zu überzeugt von Dir und suchst die Probleme aktiv wo anders.
Es ist nur nicht fair, wie Du mit einem Framework umgehst und die Schuld wo anders suchst statt _endlich _mal konzeptionell vorzugehen. Du haust nur drauf los und wunderst Dich dann.

dass das Spiel für einige ms angehalten wird.

Um es mal deutlich auszudrücken: selten so einen Schwachsinn gelesen.
Davon abgesehen, dass nicht alles angehalten wird, geht das schneller als "einige ms".
Wenn der GC Dich oder Deine Anwendung so stoppt, dass es unbrauchbar ist, dann haste nen ziemlich groben Quatsch zusammen geschustert.

Hier im Forum sind nicht nur Anfänger.
Es gibt hier durchaus mehr als nur eine Handvoll Leute, die sehr komplexe und aufwändige Software schreiben, die etwas mehr können als eine Taschenrechner-App.
Behandle potentielle Helfer nicht so, als ob sie nicht wüssten würden, wovon sie reden.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich haue drauf los? Wo? Auf wen? Ich greife im Gegensatz zu dir niemanden persönlich an sondern äußere nur Bedenken, die noch keiner wirklich mit Belegen widerlegen könnte.

Ich höre hier immer nur, "das ist so. Glaub es einfach. Wir sind die Profis". Das ist keine Diskussionsgrundlage.

Ich habe Links gepostet in denen klar steht, dass der GC ALLE Threads stoppt. Der "alte" GC teilweise bis 500ms, der neue bis zu 150ms. Du hast selbst bestätigt, dass der GC ein "Stop-the-World" verhalten hat.

Ich habe von euch nur Behauptungen gehört, die ich glauben soll. Ihr habt noch keine Belege gebracht, die meine Befürchtung entkräften.

Das ist ein Diskussionsforum, keine Religionssekte.

16.806 Beiträge seit 2008
vor 6 Jahren

Nein, das habe ich nicht gesagt.
Ich habe nicht den GC verallgemeinert, was Du hier dauernd versuchst zu entlocken, damit Du Dich bestätigt fühlst (?), denn es gibt zwei verschiedene. Siehe auch:

Es ist schon wahr, dass der "background collector" ein Stop-The-World Collector darstellt.
Alle Threads werden dabei gestoppt, dann wird gecleaned, und dann die Threads wieder "gestartet".
Beim Concurrent Collector wird nur ein Teil des Heaps gelockt, sodass es hier Stop-The-World Symptome nicht auftreten.

Und auch jeder einzelne Art des GC kann nicht einfach so verallgemeinert werden. Da existieren viele Abhängigkeiten.

Die Leute versuchen Dir hier zu helfen, was Du irgendwie nicht ganz verstanden hast. Das jedenfalls ist mein Eindruck.
Ich hab das Gefühl Du willst nichts anderes, als dass die Leute Dich bestätigen - in was auch immer - statt, dass Du eine allgemeine Lösung haben willst, die sich von Deinem Konzept evtl. unterscheidet. Willst Du mit dem Kopf durch die Wand, oder willst Du eine Lösung?
Keiner muss Dir hier was beweisen; niemand ist Dir hier Rechenschaft schuldig.

Keiner hier stellt sich so arrogant dar, dass er sagt: wir sind profis, glaub uns. Das bringt ja auch nichts.
Die Leute investieren aber hier ihre Freizeit, um Dir zu helfen - oder versuchen Dir zu helfen.

Alles ist Open Source und dokumentiert: schau Doch einfach selbst nach, wenn Du denkst die Leute hier sagen Dir nicht die Wahrheit..? 🤔
Ich mein, Du öffnest hier Threads über Grundlagen wie Process vs Threads, wie man Software modularisiert aber dann kommste in die Tiefen des .NET Frameworks und behauptest Dinge über den GC, wo man irgendwie sich (jedenfalls tu ich das) nur fragen kann: what?
Ebenso liest Du irgendwie keine Links, die man Dir gibt (egal obs die FAQ ist oder GitHub Links zu C# Scripting).

Ich mein: was erwartest Du denn für eine Antwort? Soll man hier solange im Kreis diskutieren, bis Du recht bekommst, damit Du recht bekommst?

Deine Ausgangsfrage ist immer noch: Ist Mono geeignet für Sandbox Spiele wie Minecraft?
Und das kann man ganz klar mit Ja beantworten. Willst Du das nun diskutieren, oder gehts Dir eigentlich nicht mittlerweile darum, wie man unabhängig von Mono und des GC sowas umsetzt?

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich möchte aus einem Link zitieren, den ich weiter oben schon einmal gepostet habe.

With concurrent garbage collection, we are able to perform collections on the old generation (what we call major collections) mostly concurrently with your application - it happens at the same time as your program is running. When the major collection is completed, the collector only needs to pause the Mono threads for a very brief period of time at the end.

Auch in einem anderen Link wurde aufgezeigt, dass der GC die Länge der Pausen nur erheblich reduziert, aber nicht völlig eliminiert

Also selbst mit dem Concurrent GC findet ein "Stop-the-World" statt, nur eben nicht mehr so lang

Ich mache mir hier trotz mieser Bedingungen (Internet nur über Handy und 64k Bandbreite) die Mühe, Belege für meine Aussagen zu suchen und ich lese auch, was da steht

Ich suche hier keine Bestätigung für irgendwas. Ich möchte hier vernünftig diskutieren können. Ich bringe Belege dafür, dass meine Aussagen den GC betreffend stimmen, die wohl niemand gelesen hat.

Es steht da eindeutig, dass auch der neue CGC alle Treads stoppt, nur eben erheblich kürzer.

Sollte es da irgendwelche Ausnahmen geben oder wenn ich irgendwo einen Denkfehler habe würde ich mich über entsprechende Belege freuen. Wenn ich falsch liege bin ich gern bereit, das zuzugeben. Aber im Moment steht Beleg gegen Aussage.

Es würde mir schon mal helfen, wenn ihr ein paar Links posten könntet, wie der GC arbeitet und was man da optimieren kann. Auch Tante Google hilft da oft nicht weiter, wenn man nicht die richtigen Stichwort für die Suche kennt. Oft findet man Seiten, die 10 Jahre und älter sind. Ich kann aber leider nicht beurteilen, ob die Informationen noch gelten.

16.806 Beiträge seit 2008
vor 6 Jahren

Was Du betreibst nennt sich: premature optimization is the root of all evil
Ein typisches Vorgehen, wenn man die Fehler an der falschen Stelle sucht und/oder Verantwortung von sich weist.
Der ganze Quote dazu:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Statt Dein eigenes Konzept, Code, Architektur als Ursache zu untersuchen und ggfls auszuschließen, suchst Du direkt ohne ersichtliche Gründe die Fehler in der Umgebung.
Einmal ToList zuviel aufgerufen ist deutlich teurer, als der GC.

Du magst mit Deinen Belegen recht haben, das Gegenteil sagt hier auch keiner; ich bezweifle - und nimm mir das nicht übel - aber massiv, dass Du bei Deinem Kenntnisstand, der aktuell basierend auf Deinen Threads hier, die nächste Zeit überhaupt in die Nähe kommst, dass der GC Dein Performance-Nadelöhr ist.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Du verstehst mich falsch. Ich habe noch kein Konzept. Ich entwickle es gerade. Ich habe schon einiges an Erfahrung mit Voxel Games, aber noch wenig mit Garbage Collectors.

Ich weiß, wie kritisch das Timing bei Spielen ist und ihr müsst schon verstehen das die Alarmglocken schrillen können, wenn man davon liest, dass der GC einfach mal für mehrere ms alles stoppen kann

Unity als Beleg zu nehmen, dass es geht, bringt nichts weil niemand weiß, wie Unity intern aufgebaut ist, es sei denn hier arbeitet jemand für die Firma oder hat für den Source Code bezahlt. Oder ist irgendwo der interne Aufbau beschrieben oder ersichtlich?

Es hat auch nichts mit premature optimization zu tun. Ich habe leider schon zu oft erlebt das Projekte (nicht meine) in einer Sackgasse gelandet sind, weil sie ohne tiefgreifende Änderungen ein Problem nicht lösen konnten. Ein Projekt ist das Voxel Game, an dem ich zum Teil mitgearbeitet habe. Das steckt fest und die Kernentwickler versuchen jetzt, mit haarsträubenden Methoden die Kurve zu kriegen, weil sie das Kernproblem nicht lösen können oder wollen.

Ich versuche hier nicht zu optimieren. Es hat nichts mit optimieren zu tun wenn man von vorn herein versucht, grundlegenden Problem aus dem Weg zu gehen.

Wie gesagt, ich bin bereit zu lernen, aber ich bin auch das sprichwörtlich gebrannte Kind, dass das Feuer scheut.

Das Feuer sind im Moment bis zu 150ms kompletter Stillstand, auch beim CGC und ich kann nicht beurteilen, ob die irgendwann zu einem Problem werden können, die große Änderungen erforderlich machen. Im Moment muss ich auf eure Aussagen vertrauen.

Mag sein, dass du das schon "optimieren" nennst, für mich ist das vorausschauend planen.

16.806 Beiträge seit 2008
vor 6 Jahren

Davon abgesehen, dass aus der Erfahrung Dein Vorgehen alles Vorherzusehen zum Scheitern verurteilt ist, glaubst Du wirklich, dass Du bei Deinem .NET Kenntnisstand (und Programmierkenntnisstand) in die Situation kommst, dass nicht Dein Code sondern der GC der Flaschenhals ist? Wie gesagt: einmal ToList falsch aufrufen ist teurer als einmal GC Clean.
Ganz ehrlich: sowas beachtet man am Anfang nicht mal bei sehr sehr großer Software, die etwas mehr leistet, als Voxel Games; weil nicht hilfreich.

Du schaffst Dir gerade mehr Probleme, als dass Du irgendwelche löst oder ausschließt.
Aber nun bin ich endgültig raus, weil das bringt nichts.
Manchmal muss man Leute auch einfach mal Fehler machen lassen, dass sie sehen, auch wenn man selbst sieht, dass sie mit Vollspeed gegen die Wand fahren.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich geh dann Mal deinen Weg und fahre dann auch gegen deine Wand, wenn es so weit ist, einverstanden?

5.657 Beiträge seit 2006
vor 6 Jahren

Hi burli70,

Ich habe jetzt keine konkrete Quelle, ist aber das, was immer behauptet wird.

Ich habe von euch nur Behauptungen gehört, die ich glauben soll. Ihr habt noch keine Belege gebracht, die meine Befürchtung entkräften.

Ihr habt mich falsch verstanden.

Du verstehst mich falsch.

ich bin auch das sprichwörtlich gebrannte Kind, dass das Feuer scheut.

Das klingt für mich alles eher, als suchst du jemanden, der dir gut zuredet. Wenn du konkrete Hilfe brauchst, oder ein konkretes Problem mit der Speicherverwaltung hast, dann erkläre, was du gemacht hast, und zeig uns den relevanten Code, siehe [Hinweis] Wie poste ich richtig?, Punkt 1 und 5.

Das ist ein Diskussionsforum, keine Religionssekte.

Ich geh dann Mal deinen Weg und fahre dann auch gegen deine Wand, wenn es so weit ist, einverstanden?

Was genau möchtest du damit erreichen? Wir möchten hier keine Diskussionen auf dieser Ebene führen, siehe noch einmal [Hinweis] Wie poste ich richtig?: "Wir erwarten von allen einen höflichen und respektvollen Umgang miteinander." Bitte halte dich daran und diskutiere mit uns auf einer sachlichen Ebene. Wenn du dazu nicht in der Lage sein solltest, wird der Thread von den Moderatoren geschlossen.

Weeks of programming can save you hours of planning

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich bin einfach unsicher, was den GC angeht. Ich möchte nicht unnötig in einer Sackgasse landen, die man vermeiden könnte. Nur leider hat mir noch niemand diese Unsicherheit nehmen können.

Meine letzte Aussage war lediglich eine patzige Antwort auf unnötige persönliche Angriffe gegen mich, die in einem Diskussionsforum nichts verloren haben

16.806 Beiträge seit 2008
vor 6 Jahren

Dieser ganze Thread hier ist eine totale Sackgasse, er ist absolut sinnfrei, weil es absolut unklar ist, was für eine Antwort Du erwartest. Es verfehlt den Sinn eines Forums.
Wie gesagt: niemand ist Dir irgendwas schuldig beweisen zu müssen. Das ist nicht der Sinn eines Forums.
Das Forum hier ist eine sachliche Diskussionsplattform und nicht dazu da, Dich an der Hand oder Deine Verantwortung zu übernehmen oder gar für Dich Entscheidungen zu treffen.

Ein Forum gibt Tipps und Hilfestellungen zu konkreten Dingen.
Entscheidungen musst Du selbst treffen und verantworten.
Du wirst nicht in 3 Jahren jammern können: aber der und der aus dem Forum hat das gesagt !!!!!1111elf.
Du verantwortest Deine Entscheidungen ganz alleine.

Genug Lektüre und Hinweise, wie der GC funktioniert, was er macht - worauf Du wirklich achten solltest - und wie Du Dich selbst hierzu belehren kannst, hast Du erhalten.
Was erwartest Du denn noch für eine Antwort?
Ich frage das nicht, weil ich erwarte, Dir zu helfen - der Zug ist abgefahren - sondern weil wir langsam in den Bereich kommen, dass der Thread kein Sinn mehr macht und die Foren-/Communityregeln untergräbt.

PS: patzigen Antworten führen erfahrungsgemäß dazu, dass Leute sich Deine Art und Weise merken und in Zukunft (zurecht) nicht mehr helfen werden.

C
1.214 Beiträge seit 2006
vor 6 Jahren

Ich bin einfach unsicher, was den GC angeht. Ich möchte nicht unnötig in einer Sackgasse landen, die man vermeiden könnte.

Ich hab mich bisher bewußt herausgehalten, und wüsste auch nicht, ob man dir hier überhaupt eine sinnvolle Antwort geben kann. Ich selber bin schon lang von .NET auf C++ umgestiegen und würde die Sprache sowieso bevorzugen. Aber nicht unbedingt weiterempfehlen. Die Sprache ist nicht für jeden was. Ich mach das wahrscheinlich schon seit 15 Jahren, seit 7 Jahren hauptberuflich, und trotzdem entdecke ich immer wieder etwas neues, was mir nicht klar war. Man braucht viel länger, bis man damit sinnvoll arbeiten kann, mit C# kann man viel schneller loslegen. Wenn dir C++ liegt und du Gefallen daran findest, dann mach das. Aber wenn du sagst, du machst es, weil du das wahrscheinlich machen musst, dann wird das nichts.
Ich geh auch überhaupt nicht davon aus, dass der GC hier großartig Probleme machen wird. So ein Spiel ist schon etwas komplexer, da gibts verschiedene Möglichkeiten, wie man sowas aufbauen könnte. Probier das doch einfach mal aus. Mach ein paar einfache Tests, schau, obs performant genug läuft. Wenn nicht, versuche rauszufinden, was das Problem ist, und das evtl. anders aufzubauen.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich habe etwas weiter gegraben und der GC von Java scheint einen Einfluss auf die Performance zu haben. Es gibt gefühlt ein Dutzend GC für Java und jeder hat andere Erfahrungen. Bei dem einen bringt GC X 50% mehr Frames, bei dem anderen gar nichts, dafür hat er bei GC Y 20% mehr usw.

C++ ist für mich ein Buch mit sieben Siegeln. Nicht nur die Sprache sondern auch das ganze Umfeld mit make und configure usw. Ich hab früher viel in C programmiert, aber da nur auf einem Mikrocontroller, da war das Umfeld überschaubar.

Ein anderer Grund, warum ich eher auf C# setzen möchte ist Scripting. Die schnellste mir bekannte Möglichkeit, in C++ Scripte auszuführen ist LuaJIT. Der hat aber das Problem eines Speicherlimits, mit dem ich schon zu tun hatte. Alles andere an embedded Scripten ist aber gleich um Längen langsamer. Und C# als Scriptsprache in C++ einbinden ist glaube ich auch eher so lala

Wie ich bereits früher gesagt habe: sollte sich der GC als Flaschenhals heraus stellen sollte es eigentlich möglich sein, die kritischen Daten am GC vorbei direkt zu speichern.

463 Beiträge seit 2009
vor 6 Jahren

Ich habe mir jetzt die Mühe gemacht und den ganzen Thread gelesen - dumme Frage: Warum fängst du nicht einfach mal an zu entwicklen?

Geh weg von deiner Wasserfall Metgode hin zu agiler Entwicklung... Ansonsten wirst du in 2 Jahren noch versuchen ein Konzept zu entwickeln, da die in der Zwishcenzeit noch 100 neuer kritischer Punkte eingefallen sind.

PS: Mit dieser Methode lernst du auch nebnezu deine Erfahrung in C# zu verbessern und umschiffst damit viele Problem in der Zukunft 😃

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Ich bin schon dabei. Monodevelop läuft schon heiß 😉

Ich programmiere aber noch nicht das Spiel selbst sondern ich mache erst mal getrennte Projekte für einzelne Komponenten wie Datenbank, Scripting, Noise Generator, Client Server Kommunikation usw

C
1.214 Beiträge seit 2006
vor 6 Jahren

Ich programmiere aber noch nicht das Spiel selbst sondern ich mache erst mal getrennte Projekte für einzelne Komponenten wie Datenbank, Scripting, Noise Generator, Client Server Kommunikation usw

Dann könntest du theoretisch aber auch Programmiersprachen mischen. Also, z.B. Rendering in C++, und Datenbank, Scripting, Networking usw. in C#.
Deine Probleme mit dem Scripting in C++ kann ich jetzt nicht bestätigen. Es gibt dutzende oder hunderte Scriptsprachen, die du in C++ einbinden könntest. Einen Speicherlimit bei Lua (JIT oder nicht ist erstmal zweitrangig) kenne ich jetzt nicht, sowas müsste man sich schon im Detail anschauen.

B
burli70 Themenstarter:in
57 Beiträge seit 2016
vor 6 Jahren

Dann könntest du theoretisch aber auch Programmiersprachen mischen. Also, z.B. Rendering in C++, und Datenbank, Scripting, Networking usw. in C#.

Wie ich weiter oben schon geschrieben habe bin ich kein C++ Fan. Ein Mischmasch aus C++ und C# würde es noch schlimmer machen

Deine Probleme mit dem Scripting in C++ kann ich jetzt nicht bestätigen. Es gibt dutzende oder hunderte Scriptsprachen, die du in C++ einbinden könntest. Einen Speicherlimit bei Lua (JIT oder nicht ist erstmal zweitrangig) kenne ich jetzt nicht, sowas müsste man sich schon im Detail anschauen.

Klar gibt es viele Scriptsprachen. Die sind aber alle zu langsam. Einzige Ausnahme ist der LuaJIT. Nicht umsonst wird der eher mit C und Java verglichen als mit Python & co. In manchen Benchmarks soll er sogar C schlagen. Aber der hat, zumindest bei einem anderen Projekt, an dem ich mitarbeite, ein Limit bei ca 1GB. Danach gibt er auf.

Google mal nach "LuaJIT memory limit". Der LuaJIT arbeitet wohl nur mit einem 31 Bit Adressraum