ZFX + Developia

Hallo,
Ich bin noch an der Planung des theoretischen Teils für mein Spiel, genauer der KI und der Wissensrepresäntation. Daher wollte ich hier mal nach Meinungen, Techniken und Fallstricken fragen.
Ich habe ein komplexes Spieluniversum mit hierarchich angeordneten Elementen (Sternensysteme enthalten Planeten die enthalten Parcellen usw). Es gibt auch noch viele Asteroiden, Monde usw und alle enthalten multiple Eigenschaften. Ob eine Eigenschaft (zb Erzgehalt) von der KI sichtbar ist hängt von Scannstärke, Entfernung und solchen Faktoren ab (also jeder sieht etwas anderes). Solches Wissen kann auch zwischen den einzelnen Fraktionen getauscht werden (zb über Diebstahl, Handel, Kauf usw). Mein Dilemma ist jetzt die interne Repräsentation des Wissens das eine Fraktion zusammengetragen und worauf sie Zugriff hat. Ich kann ja nicht für jede Fraktion eine Kopie des gesamten Universums (aus ihrer limitierten Sensorsicht) im Speicher halten mit einem Flagg was sie kennt und was nicht.
Daher hier meine Frage was ihr mir für Denkansätze empfehlen würdet.

Als Diskussiongrundlage mal meine (noch nicht sehr weit fortgeschrittenen) Gedanken dazu.
Es würde sich anbieten das Universum hierarchich in einem Baum zu verwalten. Ebenso wäre das für die KI günstig.

Eine Möglichkeit wäre einen Baum für jede Fraktion zu haben in dem alle ihr Bekannten Objekte enthalten sind. Erstens wird eine Fraktion nie alles kennenlernen und zweitens wird die Anzahl der Fraktionen im Spielverlauf auch kleiner werden ;). Also sobald das Wissen über ein Objekt auf irgendeine Art erworben wurde wird es in den Baum kopiert. Das Problem ist hier dass sich die Eigenschaften ja auch ändern können (zb wenn das Erz jemand abbaut). Das wäre also realistisch dass die KI davon ausgeht es wäre noch da bis sie neu scannt und es merkt. Dann muss das Objekt wieder rausgesucht und upgedated werden. Das würde über eine Objekt-ID geschehen die eindeutig ist. Wobei sich an den Objektids der parents entlangehangelt wird also nicht der ganze baum durchsucht werden muss.

Es müssen aber auch Tabellen bzw abfragen schnell möglich sein zb um zu entscheiden auf welchem Asteroiden die nächste Mine oder Basis gebaut wird. Und mobile Einheiten wie Flotten müssen auch den Objekten zugeordnet werden zb wenn sie an einem Planeten auftauchen und gesichtet werden. Da werden dann Fragen aktuell wie "wo bekomme ich am schnellsten Verstärkung her?" wobei da auch komplexe Pfade durch Sprungtore möglich sind. Es müsste also so sein dass die KI auf ihrem limitierten Baum Entscheidungen trifft.

Ich hoffe ich konnte die Situation erläutern und würde gern hören wie ihr sowas machen würdet bzw welche Sachen ich am Konzept ändern muss um es überhaupt möglich zu machen. Ich kenn mich auch nicht so besonders mit KI aus und hoffe ich gehe nicht zu naiv ran.
Danke und Gruß
Despotist

Ich würde die Objekte nicht kopieren, weil im schlechtesten Fall jede Deiner Fraktionen eine komplette Kopie Deines Universums hat bzw. einen großen Teils vorhält, bei einer Fraktion bestimmt noch kein Problem, aber wie ist das bei 5 oder 10 Speichermässig?
Selbst wenn Du sagst das soll so nicht sein, dann musst Du der KI ja verbieten in bestimmte Systeme/Sektoren/Whatever zu fliegen, damit diese nicht in Deine Liste/Baum eingefügt werden.

Ich würde jeder Fraktion einen Zeiger auf das bekannte Objekt spendieren. Evtl. würde ich mir die Zeit seit dem letzten Besuch/Scan mit dem Zeiger auf das Objekt merken und bei überschreiten eines bestimmten Wertes muss die KI halt nochmal hin und die Zeit aktualisieren, entspricht also Deinem Scan.
Die sich verändernden Werte sind ja kein echtes Problem, Zeit abgelaufen, KI muss erst nochmal hin bevor Sie was machen kann mit dem Objekt. Zeit noch nicht abgelaufen, wunderbar KI darf hin und alles machen. Du brauchst die Werte ja sowieso für die KI um zu entscheiden ob Sie da jetzt hinfliegt oder und irgendwas abbaut oder doch nicht.

So sparste Dir auf jeden Fall schonmal das kopieren von Objekten und das Updaten von irgendwelchen Objekt-Kopien.

Mein erster Gedanke war, dann bei jedem Objekt ein kleines Array für jede KI bzw. auch für den Spieler zu halten. Also wenn es 10 Spieler/KI gibt, dann hat die Eisenerzmine elf Werte. Den Echten und in dem Array für jeden Spieler den bekannten Wert.
Ich befürchte aber, dass dadurch Suchanfragen wesentlich langsamer wären, weil man immer das komplette Universum durchsuchen muss, um herauszufinden, was ein einzelner Spieler weiss.
Da ist es eigentlich wirklich besser, wenn jeder seine eigene Vorstellung des Universums hat. Möglich wären dadurch auch dynamische Veränderungen. Wenn z.B. eine Sternenstrasse geändert würde, aus welchem Grund auch immer, würden die Spieler erstmal davon ausgehen, dass die Verbindung noch existiert und erst bei erneutem scannen feststellen, dass dies alte Informationen waren.
Um den Speicherverbrauch würde ich mir nicht so viel Sorgen machen. Zumal man ja auch Baumteile in denen gerade nicht gespielt bzw. die unrelevant sind, weil sie zur Zeit zu weit weg sind auf Festplatte auslagern könnte.

Auslagern ist ein guter Ansatz, aber nutzlos, wenn dir bei so vielen Mini-Objekten (unter 32 Bits) der Adressraum weg fragmentiert …

Ich würde definitiv jede Fraktion ihre eigene Vorstellung vom Universum haben lassen, aus den schon genannten Gründen, dass sie z.B. Verbindungen regelmäßig inspizieren muss um zu sehen, ob sie noch aktiv ist. In der Realität ist es ja auch nicht anders, da stützt man sich auf die Karten, die man hat, und solange niemand dabei ist, wenn sich was verändert, bleiben die Karten fehlerhaft.
Dabei würde ich ganz besonders viel Wert darauf legen, möglichst viele Werte zu kapseln, und unnötige Indirektionen zu vermeiden … vielleicht auch Bäume auf lineare Arrays abrollen … das Hauptproblem sehe ich nämlich nicht im Speicherbedarf (ein Gros des Bedarfs dürfte weiterhin für Texturen und Geometrie draufgehen, die Datenmenge von spielmechanisch relevanten Werten sollte selbst bei millionen Systemen noch nicht übliche RAM-Grenzen sprengen – aber es macht sich vllt dennoch gut, virtuelle Funktionen zu vermeiden), sondern in dem Overhead bei der Verwaltung von hunderten Millionen einzelner Werte, die einzeln allokiert im Adressraum rumfliegen.

Weiterhin kannst du dieselbe Optimierung anwenden wie beim Rendering auch: LoD für die KI. Also z.B. Sektoren, die so weit entfernt sind, dass sie nicht mehr relevant für das Spielgeschehen sind, abwechselnd alle paar hundert Frames updaten und dabei weniger detaillierte Datensätze benutzen, die du extra für das Update generierst / aus Dateien lädst und sofort wieder freigibst.

Gruß, Ky

Ich sprach auch nicht von Mini-Objekte auslagern, sondern eher davon komplette Zweige des Universums auszulagern, falls wirklich eine Begrenzung durch den Speicher auftreten sollte.

Das LoD für die KI ist eine gute Idee. Dabei fällt mir dann noch ein Mipmapsystem ein (Edit: Vielleicht ist das auch das, was Krishty meinte). Es muss z.B. ermittelt werden, wo man am effektivsten Erz herbekommt. Dann könnte das Erz für ein Sonnensystem zusammengerechnet werden, dann hierarchisch für Sonnensystemsgruppen, Galaxiequadranten usw.
Somit müsste, wenn nun ermittelt wird, wo das meiste Erz ist, nicht jedes bekannte System des Baumes durchgegangen werden, sondern es reicht ein kurzer Blick auf die Summe, und wenn sich das dann lohnt, dann kann man ja detaillierter vorgehen.
Über ein solches Verfahren könnte man dann auch nochmal über ein gute Streamingverfahren nachdenken, weil die Speicherintensiveren Detailinformationen ja komplett ausgelagert sein könnten und nur ein kleiner Teil im RAM sitzt.

Zudomon hat geschrieben:Ich sprach auch nicht von Mini-Objekte auslagern, sondern eher davon komplette Zweige des Universums auszulagern, falls wirklich eine Begrenzung durch den Speicher auftreten sollte.

Es ist egal, wie groß die Teile sind, die du auslagerst – wieviel Speicher du langfristig nutzen kannst hängt letztendlich davon ab, wie klein die Blätter des Baumes sind, der im RAM liegt.

Ok, erstmal danke für die Denkansätze. Langsam konkretisiert sich das Bild wie es NICHT gehen könnte ;). Zur Information noch bezüglich der Fraktionen ist geplant dass es einige hundert geben kann. Und das Universum soll auch aus recht vielen Objekten bestehen und in Echtzeit laufen. Weiterhin ist es ja möglich dass Fraktionen ihr Wissen über das Universum durch Tausch, Verkauf und Diebstahl teilen. Also muss es eine Art Pool geben wo solche geteilten Informationen nur einmal gespeichert und dann von allen Beteiligten referenziert werden. Aber ich frage mich ob das ganze wirklich mit den Parametern vernünftig umgesetzt werden kann da die Verwaltung enorm wäre. Vielleicht muss ich das Konzept vereinfachen ohne die gewünschte Mechanik zu zerstören.

Zudomon hat geschrieben: Somit müsste, wenn nun ermittelt wird, wo das meiste Erz ist, nicht jedes bekannte System des Baumes durchgegangen werden, sondern es reicht ein kurzer Blick auf die Summe, und wenn sich das dann lohnt, dann kann man ja detaillierter vorgehen.

Das geht meiner Ansicht nach nicht. Beispiel: Ich suche mir den Quadranten mit dem meisten Erz aber der liegt im Feindgebiet. Oder ich nehme System X weil die Summe da am höchsten ist sich aber auf 10 Planeten aufteilt und in System Y ist nur ein Planet der aber die höchste Dichte hat und somit vorteilhafter wäre da ich ja nur auf einem Planeten abbauen kann. Also muss ich schon alle Planeten direkt testen und mit anderen Eigenschaften wie Entfernung oder (Un)sicherheit eine Bewertung für die KI erzeugen.

Das ganze Universum soll ja auch prozedural erzeugt werden. Da wäre noch eine Idee anstatt die gescannten Werte zu speichern eine Information über die Scanstärke zu speichern und dann bei Bedarf jedes Objekt prozedural zu erzeugen und die Scanstärke darauf anzuwenden. Aber die Laufzeitperformance stelle ich mir noch schlechter vor.

Was auch gehen könnte ist dass gezielt nur die wichtigsten zweckgebundenen Parameter gespeichert werden. Also z.B. für den Abbau von Erz F werden nur Referenzen auf Planeten gespeichert die das Erz in einer bestimmten Mindestmenge/Konzentration enthalten.
Das ganze kann in einem Array gespeichert werden und ich kann aufgabenbezogen nur dieses eine Array durchsuchen um eine gute Entscheidung zu treffen also Mengen und Entfernungen mit einbeziehen.
Wenn ich eine neue Info bekomme zb über einen Planeten schaue ich was es auf dem gibt. Z.B. Erz G also gehe ich in das Array der abbauwürdigen Erz G Vorkommen und sortiere den Wert da ein oder auch nicht wenn er unterhalb des Grenzwertes liegt. Durch Variation des Grenzwerts bin ich auch flexibel und kann bei viel Speicher mehr Möglichkeiten merken als bei wenig. Je mehr ich darüber nachdenke umso besser gefällt mir die Idee wobei es natürlich eine ganze Menge Aufgaben für die KI gibt die so alle einzeln in einem Array verwaltet werden müssen. Aber so erscheint mit die Verwaltung am einfachsten und der Zugriff am zielgerichtetsten und es werden keine unnötigen Infos gespeichert. Was natürlich schwierig wird ist die Bewertung der Umstände also ob ein Vorkommen im Feindgebiet oder am anderen Ende des Universums liegt was enorme Transportwege bedeutet. Aber durch das Speichern der Referenz auf den Planeten der sein System kennt kann ich die Infos zusammentragen und bewerten um die beste Option zu ermitteln.
Ich könnte auch einfach eine feste Anzahl der besten Möglichkeiten merken statt einem Grenzwert dadurch würde es noch einfacher und der Speicherbedarf besser abschätzbar und einstellbar.

Wenn noch Ideen sind nur her damit. Andernfalls Besten Dank.
Despotist

Despotist hat geschrieben: Was auch gehen könnte ist dass gezielt nur die wichtigsten zweckgebundenen Parameter gespeichert werden. Also z.B. für den Abbau von Erz F werden nur Referenzen auf Planeten gespeichert die das Erz in einer bestimmten Mindestmenge/Konzentration enthalten.
Das ganze kann in einem Array gespeichert werden und ich kann aufgabenbezogen nur dieses eine Array durchsuchen um eine gute Entscheidung zu treffen also Mengen und Entfernungen mit einbeziehen.
Wenn ich eine neue Info bekomme zb über einen Planeten schaue ich was es auf dem gibt. Z.B. Erz G also gehe ich in das Array der abbauwürdigen Erz G Vorkommen und sortiere den Wert da ein oder auch nicht wenn er unterhalb des Grenzwertes liegt. Durch Variation des Grenzwerts bin ich auch flexibel und kann bei viel Speicher mehr Möglichkeiten merken als bei wenig. Je mehr ich darüber nachdenke umso besser gefällt mir die Idee wobei es natürlich eine ganze Menge Aufgaben für die KI gibt die so alle einzeln in einem Array verwaltet werden müssen. Aber so erscheint mit die Verwaltung am einfachsten und der Zugriff am zielgerichtetsten und es werden keine unnötigen Infos gespeichert. Was natürlich schwierig wird ist die Bewertung der Umstände also ob ein Vorkommen im Feindgebiet oder am anderen Ende des Universums liegt was enorme Transportwege bedeutet. Aber durch das Speichern der Referenz auf den Planeten der sein System kennt kann ich die Infos zusammentragen und bewerten um die beste Option zu ermitteln.
Ich könnte auch einfach eine feste Anzahl der besten Möglichkeiten merken statt einem Grenzwert dadurch würde es noch einfacher und der Speicherbedarf besser abschätzbar und einstellbar.

Wenn noch Ideen sind nur her damit. Andernfalls Besten Dank.
Despotist

Ich glaube nicht das es ein Problem wird zu ermitteln ob der Sektor z.B. im Feindgebiet liegt. Letztlich hat jeder Spieler, egal ob KI oder nicht, eine Liste von Sektoren die Ihm bekannt sind.
Ich würde dafür einfach dem Sektor einen Zeiger auf den owner spendieren.
So kannste ganz fix prüfen ob dieser Sektor jemandem gehört und wenn ja ob es Freund oder Feind ist, da deine KI ja sowieso eine Liste von Freunden und Feinden haben muss.

Wie wäre es mit einer Datenbank? Jeder Knoten, jedes Blatt usw. hat eine globale ID... Dann musst du dir nur noch ein vernünftiges ERM ausdenken und das wars... Solange etwas nicht bekannt/prozedural generiert wurde existiert es dann einfach nicht in der Datenbank... Um dann rauszufinden welche Erzvorkommen der KI "XY" bekannt sind machst du dann einfach eine Selektion auf der Datenbank vielleicht so (oder ähnlich:)):
SELECT r.nodeGlobalId FROM resources r INNER JOIN knowledge k ON r.globalID=k.targetGlobalId WHERE r.type=ORE AND k.owner=XY

In diesem Fall gäbe es dann eine Tabelle knowledge. Diese ist im Grunde eine n:m Relation zwischen globalen IDs und Spielern... Ggf. könnte man diese Wissensrelation noch mit Attributen wie Zeitpunkt der Wissenserlangung o.Ä. anreichern. Wenn du dann noch falsches Wissen integrieren möchtest, würde ich einfach allen Dingen noch eine Art "istAusgedacht"-Attribut mitgeben. Solange man dann nicht das echte Wissen erlangt hat, kennt man eben nur die flaschen Informationen (bspw. Verweise auf Ressourcen mit istAusgedacht=true). Ebenfalls wäre es möglich eine Art Güte Attribut in die knowledge Relation mit zu geben. Die Güte gibt dann die Genauigkeit der Informationen an, die ein Spieler über die Entitäten abfragen kann.

Integrierte Datenbanksysteme würden dir so ziemlich viel Arbeit abnehemn. Und du müsstest dich nicht um Caching etc. kümmern... Und wenn du den Rest deiner Daten auch in der Datenbank ablegst ist das ganze elegant und aus einem Guß...

Auf bald
Chromanoid

Hallo Chromanoid,
ich habe lange darüber nachgedacht was sich durch die Verwendung einer Datenbank ändern würde. Hier meine Schlüsse:
1) Die Verwaltung würde komplizierter werden da ich die Strukturen und Klassen, die ich sowieso benötige für Entscheidungen der KI, genauso implementieren muss und zusätzlich noch den Transfer von und in die Datenbank was ja auch seine Laufzeit braucht.

2) In der Datenbank habe ich nur die IDs der Objekte (z.B. Planeten) worauf sich die Infos beziehen. Das heißt dass ich anhand der ID das zugehörige Objekt durch traversieren des Baumes immer erst noch finden muss während es mit dem Build-In Ansatz direkt referenziert wird.

3) Sollten Änderungen auftreten (ich wills nicht hoffen ;)) muss ich auch die Datenbank und den Import/Export anpassen und testen statt wie in meiner Lösung nur die Datenstrukturen und ihre Serialisierung (die ich in beiden Fällen brauche).

4) Ich habe direkte Kontrolle darüber wie viele Objekte ich speichere während ich wenig bis keine Kontrolle über den Speicherbedarf der Datenbank habe.

Zusammengefasst sehe ich die Datenbanklösung als zusätzlichen Aufwand einfach um Objekte zu speichern und zu verwalten was ich sowieso machen muss der aber ein großes Potential an zusätzlichen Risiken birgt und mir wenig Kontrolle lässt.

Das mal als Diskussionsgrundlage. Wenn ich was übersehen habe oder falsch einschätze bitte korrigieren. Ich habe zwar mal in einem größeren Projekt bei der Arbeit eine Access Datenbank mit Ado.net betrieben war aber nicht sehr begeistert was Performance und "Einfachheit" angeht. Also scheue ich erstmal den zusätzlichen Aufwand wobei ich es gern im Hinterkopf behalte.

Danke und Gruß
Despotist

Also als Rule of Thumb hab ich im Hinterkopf dass sich eine Datenbank dann lohnt, wenn die Daten nicht gleichzeitig in einen Hauptspeicher passen.

Ich werde bei den Systemanforderungen tricksen. 16 GB RAM sollte heute jeder haben ;)

Das Spiel soll eh stark skalierbar sein und der Nutzer selber festlegen können ob er mit 10 oder 1000 Sternen und Fraktion spielt. Also kann er es gut an seine Hardware (auch zukünftige) anpassen.

Und da alles noch in der Konzeptuierungsphase steckt wollte ich halt mal Meinungen hören worauf ich achten muss. Wie gesagt habe ich lange darüber nachgedacht und finde meinen Ansatz des "Weglassens" besser. Ich habe die Datenbank aber auch nicht völlig aus meinen Überlegungen verbannt. Die Zeit wird zeigen ob es funktioniert wie ichs mir jetzt überlegt hab.

Danke
Despotist

Also für die Schnittstelle DB<->Anwendung gibt es mit Sicherheit einige gute Frameworks, die dir das komplett abnehmen. Ein weiterer Vorteil wäre evt., dass du es vielleicht bei der Netzwerkprogrammierung nachher einfacher hast (falls Multiplayer geplant ist). <EDIT>Und nicht zu verachten ist eine integrierte Abfrage-Sprache (i.d.R. SQL), um eben eine bestimmte Suche durchzuführen.</EDIT>
Hier war sonst mal ein Thread deswegen, wo man mal reinschauen könnte: http://zfx.info/viewtopic.php?f=4&t=338&p=3752 (da steht aber nicht sonderlich viel drin :))
Insgesamt ist wohl zu sagen, dass soweit ich informiert bin immer mehr Spiele embedded Databases einsetzen...

SQLite zum Beispiel, das ist wohl eine InMemory-Datenbank, für die man auf dem Zielsystem nix installieren muss. Das würde ich als Spieler als notwendige Bedingung betrachten. Und die Datenbank kann nach meinem Wissen dann auch serialisieren - das Problem wäre für Dich dann auch vom Tisch.

Ich denke, Datenbanken sind für sowas eine gute Idee. Mir fehlt da allerdings die persönliche Erfahrung - ich glaube, ich hätte mich damit schon lange mal beschäftigen sollen, aber ich habe es bislang nie gemacht.

Chromanoid hat geschrieben: dass du es vielleicht bei der Netzwerkprogrammierung nachher einfacher hast (falls Multiplayer geplant ist).

Nun, da Multiplayer auf jeden Fall geplant ist könntest du bitte erläutern inwiefern mir eine Datenbank das erleichtert? Ich hätte zu Spielstart per Serialisierung alle Daten vom Server zu den Clients geschickt und dann alle Änderungen die die Clients zurückmelden ebenso. So dass in jedem Client eine "exakte" Kopie des Spielbaumes liegen sollte die er anzeigt. Wenn ich ne lokale Datenbank beim Client verwende wie kann ich dann "kleine" Updates durchführen? Oder soll der Client auf die Serverdatenbank zugreifen?
Das Problem ist, dass ja dann die Anfragen eingehen und bearbeitet werden müssen. Wenn ich die Daten lokal update ist nur ein Senden vom Server notwendig und ich denke dadurch wird die Netzwerkperformance besser. Es soll ja keiner benachteiligt werden weil er ne weile auf die Daten vom Server warten muss. Aber da ich von Netzwerk noch weniger Ahnung habe als von KI wäre eine Aufklärung auch hier nicht verkehrt ;).

Chromanoid hat geschrieben: Insgesamt ist wohl zu sagen, dass soweit ich informiert bin immer mehr Spiele embedded Databases einsetzen.

Und wenn alle aus dem Fenster springen spring ich auch hinterher? ;) Und der größere Teil der Spiele wird immer noch altmodisch betrieben. Wie gesagt finde ich den Ansatz per se nicht verkehrt aber es muss signifikante Vorteile für mich bringen (am besten Entwicklungszeit) damit ich es wage.

Schrompf hat geschrieben: SQLite zum Beispiel, das ist wohl eine InMemory-Datenbank, für die man auf dem Zielsystem nix installieren muss. Das würde ich als Spieler als notwendige Bedingung betrachten.

Ich auch ;) Wenn ich es so mache würde ich mir aber trotzdem einen Überblick über die Eigenschaften aller freien DBMS's auf dem Markt anschauen.

Kleiner Hinweis noch. Entwickelt wird in C# und XNA. Ich würde also an sich auf die .Net-Container zurückgreifen.

Schrompf hat geschrieben: Und die Datenbank kann nach meinem Wissen dann auch serialisieren - das Problem wäre für Dich dann auch vom Tisch.

Ich weiß nicht ob wir uns richtig verstehen. Die gesamten Daten zu serialisieren ist nur ein Teil. Wenn ich einzelne Objekte serialisieren kann (z.b. um sie vom Server auf den Clients upzudaten) hilft mir das noch mehr. Ich denke du meinst nur die gesamt-DB zu serialisieren oder?

Schrompf hat geschrieben: Ich denke, Datenbanken sind für sowas eine gute Idee. Mir fehlt da allerdings die persönliche Erfahrung

Ich bin noch nicht ganz überzeugt ;). Und fundierte Aussagen wären mir lieber als Vermutungen (nicht böse sein). Aber da das eine weitreichende Entscheidung ist möchte ich mir auch sicher sein.

Schrompf hat geschrieben: ich glaube, ich hätte mich damit schon lange mal beschäftigen sollen, aber ich habe es bislang nie gemacht.

Deswegen will ich mir ja einen Überblick verschaffen und mich für etwas entscheiden bevor ich anfange.

Danke und Gruß
Despotist

Also wie gesagt: Hauptpluspunkt ist wohl eine integrierte Abfragesprache in der du recht schnell komplizierte Abfragen durchführen kannst.
Zusätzlich könntest du sogar alle Daten (Texturen usw.) in einer Datenbank ablegen, allerdings würde man ja dann die XNA-Contentpipeline zumindest teilweise umgehen...

Das mit der einfacheren Multiplayer-Entwicklung ist eher eine Vermutung von mir, die sich aus folgenden Überlegungen ergibt:
Jeder Spieler kennt einen Teil des Universums. Die Datenbanken der Spieler werden nur bei Bedarf synchronisiert und zwar nur an den Stellen wo es auch Sinn macht (Spieler A besucht Planet von Spieler B). Ein Großteil des Datenaustausches von eher statischen Daten wie Planeten usw. findet dann direkt über SQL Abfragen statt, die an die jew. embedded Database weitergeleitet werden. Das ganze wäre dann eher eine Art P2P Struktur, aber dadurch sehr skalierbar. Ggf. ist es sogar möglich (weiss nicht ob das eingebettete DBs unterstützen) alle lokalen Spieler-Datenbanken zu einer großen virtuellen Datenbank zusammenzufassen ohne groß programmieren zu müssen...

Die meisten MMO Spiele arbeiten übrigens mit Datenbanken (soweit ich informiert bin)... ;)

Despotist hat geschrieben: Und wenn alle aus dem Fenster springen spring ich auch hinterher? Und der größere Teil der Spiele wird immer noch altmodisch betrieben. Wie gesagt finde ich den Ansatz per se nicht verkehrt aber es muss signifikante Vorteile für mich bringen (am besten Entwicklungszeit) damit ich es wage.

naja wenn viele etwas machen dann deutet das meistens eine art best practice an... :)

Despotist hat geschrieben:

Chromanoid hat geschrieben: Insgesamt ist wohl zu sagen, dass soweit ich informiert bin immer mehr Spiele embedded Databases einsetzen.

Und wenn alle aus dem Fenster springen spring ich auch hinterher? ;) Und der größere Teil der Spiele wird immer noch altmodisch betrieben. Wie gesagt finde ich den Ansatz per se nicht verkehrt aber es muss signifikante Vorteile für mich bringen (am besten Entwicklungszeit) damit ich es wage.

Du müßtest dich beispielsweise nicht um die Implementierung einer eigenen effizienten Datenbank kümmern, was der unter anderem zur Diskussion stehende Baum ja im wesentlichen ist. Das zum Beispiel wäre ein klarer Vorteil :).

Gruß Kimmi

Wenn C# dann Sqlite und nhibernate, hab damit allerdings bisher nur kleinere Programme gemacht. Also keine echten Datenmengen gespeichert.
Ansonsten sind Datenbanken halt immer so schnell wie Sie designt wurden.
Du kannst auch Deine Struktur so scheisse designen das Du Performance verschenkst, beim lesen und oder beim einfügen, ausserdem wirst Du dann erstmal gucken und probieren müssen wie der Server am schnellsten arbeitet, also mit welchen Statements, ist nämlich völlig unterschiedlich, danach musste dann eigentlich Deine Struktur aufbauen um dann am Ende trotzdem noch Statements zu tunen da bestimmte Konstrukte schneller ein Ergebnis liefern als andere Konstrukte, unabhängig von der Indizierung.

Bei vielen Abfragen kann man die Abfragen auch von unterschiedlichen Threads bearbeiten lassen, dann bekommste allerdings auch wieder Probleme.

Dann gibt es unter umständen Probleme mit Lesesperren die manche Server setzen, die blockieren dann nämlich wieder andere etc., lange Rede kurzer Sinn.
Ne Datenbank ist schick und man kann damit auch tolle Sachen machen, aber Du holst dir damit auch zig neue Probleme an den Hals.
Schreib die Daten in ne ASCII-Datei, denk Dir ein Format aus. Von mir aus auch Binary, völlig egal. Mit der Serialisierung von .NET wirste selbst noch auf genug Probleme stoßen. :)

Hach, so viele Für und Wider. Ihr macht mir die Entscheidung nicht gerade leicht.

odenter hat geschrieben: Du kannst auch Deine Struktur so scheisse designen das Du Performance verschenkst,

Genau diese Undurchsichtigkeit schreckt mich am meisten ab. Wenn ich alles selbst verwalte kann ich mir die Sachen im Debugger oder Log anzeigen lassen und Profilen. Was die Datenbank veranstaltet bleibt mir verborgen. Und da es wahrscheinlich (Pessimist) keine klaren Regeln für ein gutes Design gibt bzw. wenn es eins gibt beißt es sich mit meinen Anforderungen beißt kann ich mich auch in eine Sackgasse manövrieren.

Ich werde es daher am besten so machen das ganze erstmal konservativ zu versuchen (Baum) und dann WENN/FALLS Probleme auftreten entweder die Anforderungen zurückschrauben oder gezielt nach Lösungen für den Flaschenhals suchen. Ich habe irgendwie keine Lust wie von odenter beschrieben Performance-Tests mit verschiedenen Statements und Strukturen zu machen.

Kimmi hat geschrieben: Du müßtest dich beispielsweise nicht um die Implementierung einer eigenen effizienten Datenbank kümmern, was der unter anderem zur Diskussion stehende Baum ja im wesentlichen ist.

Das erstellen der Objekt-Struktur in der DB ist in meinen Augen schon was ähnliches wie das Erstellen des Baums. Was nun schneller, einfacher und sicherer geht weiß ich allerdings nicht.

Chromanoid hat geschrieben: Hauptpluspunkt ist wohl eine integrierte Abfragesprache in der du recht schnell komplizierte Abfragen durchführen kannst.

Den Bedarf für "komplizierte Abfragen" möchte ich ja umgehen indem ich die Daten für die Verwendung entsprechend vorhalte, also gleich in dafür optimierten Strukturen so dass die Komplexizität weniger weh tut ;).

Chromanoid hat geschrieben: Jeder Spieler kennt einen Teil des Universums. Die Datenbanken der Spieler werden nur bei Bedarf synchronisiert und zwar nur an den Stellen wo es auch Sinn macht (Spieler A besucht Planet von Spieler B).

Dass ein Spieler nur einen Teil kennt heißt für mich nicht dass auf seinem Rechner nicht alle Daten vorhanden sein sollten. Ich stelle es mir eher schwer vor verschiedene Puzzelteile zu vereinigen (bei Bedarf) und konsistent zu halten.

Chromanoid hat geschrieben: Die meisten MMO Spiele arbeiten übrigens mit Datenbanken (soweit ich informiert bin)

Das habe ich auch gehört. Auch Elder-Scrolls Morrowind soll das machen. Allerdings strebe ich nicht so viele Spieler an. Maximal 24 oder 32.

Chromanoid hat geschrieben: naja wenn viele etwas machen dann deutet das meistens eine art best practice an.

Man schaue nur mal auf die Mode ... Ich muss da immer an Lemminge denken ;)

Edit: In dem Verlinkten Thread hatte Seraph bezüglich DB's gefragt. Vielleicht kannst du mal deine Erfahrungen äußern falls es schon welche gibt.

Das effiziente Einfügen, Suchen sprich die grundlegende Infrastruktur wäre bereits fertig implementiert und ( hoffentlich ) stavbilisiert worden. Wenn du die Infos wie Systeme, Portale, Besitzer per Relationen realisierst, kannst du IMHO da recht schnell Ergebnisse erzielen. Dazu bringen fertige Lösungen oft solch banale Dinge wie Dump des Contents zum Debuggen mit sich bzw. eine Community, die dir da bestimmt unter die Arme greifen können.
Vielleicht gibt es ja bereits ähnliche Lösungen, ich erinnere mich selber schon an mehrere Web-basierende Spiele, die was ähnliches gemacht haben.
Wenn du den Baum komplett from Scratch bauen willst, musst du dich IMHO noch um wesentlich mehr wie Aufbau, effiziente Suche etc. kümmern, da du noch gar keine Infrastruktur hast. Das alles selber zu machen, ist natürlich spannender, aber ich vermute, daß du mit einer DB-Lösung schneller voran kommst.

Gruß Kimmi

Ich bezweifle, dass man das alles direkt und perfekt im Vorfeld planen kann. Im Endeffekt ist es immer eine auf das Problem zugeschnitte Lösung. Das bedeutet letztlich, dass du deine eigenen Erfahrungen sammeln musst. Deswegen würde ich dir empfehlen dir zwar hier Ratschläge zu holen aber letztlich dann auf dein Inneres zu hören, was denn intuitiv die beste Lösung wäre. Und selbst wenn dein Universum erstmal nur 1/100 von dem ist, was du vor hast, wenn beim Multiplayer nur 2 Leute gemeinsam spielen können, wenn es nur ein KI-Gegner geben kann und wenn es dann alles noch sehr langsam läuft, dann hättest du zumindest schonmal dein Vorhaben verwirklicht. Da könntest du dann sehen, an welchen Stellen du wirklich Einschränkungen hast.
Dann kannst du dich darum kümmern.
Außerdem solltest du es so machen, wie du es am einfachsten Umsetzen kannst. Wenn du dich erst in Datenbanken einarbeiten musst und stattdessen in viel schnellerer Zeit eine eigene Lösung hinbauen könntest, dann würde ich das auch erstmal so machen.

Umso kleiner die Schritte und umso niedriger das Ziel, umso wahrscheinlicher, dass du in ein paar Wochen/Monaten wirklich was zum spielen hast. Und vor allem, worauf du dann auch aufbauen kannst!

Naja, ist nur ein gutgemeinter Rat. :D

Gruß
Zudo

Despotist hat geschrieben:Man schaue nur mal auf die Mode ... Ich muss da immer an Lemminge denken ;)

Naja Mode muss nicht effizient sein, Softwarearchitektur schon. Ich würde sagen bei Ingenieurstätigkeiten wird höchstens bei der Wahl des Vorgehensmodells nach der Mode gegangen. Bei allem anderen wird (optimaler Weise) nach Kosten/Nutzen gegangen (Ich meine hier abstrakte Kosten/Nutzen, die nicht unbedingt mit Geld zu tun haben). In der Hobbyentwicklerszene ist unter Nutzen natürlich auch als wesentlicher Faktor Spaß am Projekt, Erfahrungsgewinn usw. zu verstehen. Daher würde ich total verstehen, wenn du auf ein eigenes System zurückgreifen willst.

Nur bedenke, dass du durch Einbindung einer Datenbank ebenfalls wertvolle Erfahrungen gewinnst, du an vielen "das Rad neu erfinden" Stellen vorbei kommst und gleich mehrere Jahrzehnte DV-Entwicklung in dein Projekt einbindest und so mit hoher Wahrscheinlichkeit ein effizienteres Datenhaltungssystem benutzen kannst, als du es selbst entwickeln könntest. Und denke vielleicht auch mal an weniger bekannte Datenbankmodelle. Vielleicht ist eine Objekt orientierte DB was für dich.

Und wenn wir schon dabei sind Systeme aus der Informatik zu integrieren, könntest du dir auch mal Axiomensysteme usw. anschauen. Bei uns an der Uni gibt es auch ne Vorlesung Wissensrepräsentation, da wurden in den beiden Sitzungen, die ich besucht habe, mit solchen Logiken gearbeitet. Ich weiss aber nicht inwiefern solche Systeme in Computerspielen Verwendung finden (können) (also abgesehen von einprogrammierten ggf. intuitiv erstellten regeln). Ich vermute der Aufwand ist einfach zu groß, vernünftige Regeln für ein Spiel zu formulieren. Evt. hilft dir ja http://de.wikipedia.org/wiki/Wissensrepr%C3%A4sentation und http://www.informatik.uni-hamburg.de/WS ... WissRep05/ weiter. Allerdings geht es da eher darum Wissen anhand von Logiken möglichst präzise abzulegen, um bspw. Verhaltensregeln für Roboter zu entwickeln.

Naja grundsätzlich halte ich Datenbanken schon für geeignet um größere Datenmengen zu speichern.
Ich arbeite z.B. den ganzen Tag mit Datenbanken, und die Datenmengen um die es hier geht sind eher Penuts.
So Spieleentwicklung ist für mich eher Hobby. Allerdings verfahre ich mit Themen bei denen ich nicht sooo tief im Detail stecke eher so, am Beispiel der DB, würde ich mir ein Interface für den Zugriff auf meine Daten bauen, egal wie das konkret umgesetzt ist, und erstmal was simples implementieren, schlicht um einfach mal fertig zu werden.

Weil es auch demotivierend sein kann, wenn man sich zwar was ganz tolles überlegt hat, dann aber während der Entwicklung feststellt das man vor einem Problem steht welches ohne großen Einarbeitungsaufwand nicht zu beseitigen ist, und man eigentlich an einer anderen Baustelle weiter machen will. Und wenn das Design gut ist, dann sollte es später kein Problem sein Vorgehensweise A durch B auszutauschen.

Wenn es dann fertig ist und unzureichend ist, dann würde ich anfangen mich mehr damit zu beschäftigen und ggf. was aufwendigeres implementieren.
Interne Strukturen benötigt man so oder so.

Wobei ich noch anmerken würde das eine DB natürlich nur schnell ist wenn die Daten im Speicher liegen, und ob die DB sie nun im Speicher hält oder ich selbst macht ja nun nicht so den großen Unterschied, es sei denn ich habe die Strukturen so gebaut das es schlicht langsam ist, aber dann muss man eh optimieren, egal ob DB oder die eigenen Strukturen.

@Despotist: Vielleicht kannst du ja mal http://nhforge.org/Default.aspx ausprobieren...

Chromanoid hat geschrieben:@Despotist: Vielleicht kannst du ja mal http://nhforge.org/Default.aspx ausprobieren...

Falls jemand Interesse hat, ich kann da mit funktionierendem Beispielcode dienen. (c# mssql)

Danke für den Link und das Codeangebot und ich bin auch immer noch hin und hergerissen. Aber ich denke ich werde es besser ohne DB versuchen da ich so wenigstens eine grobe Vorstellung habe wie es in etwa laufen soll während ich mich in die Datenbank esrtmal einarbeiten müsste und da sicher auch ohne Erfahrung nichts sonderlich gescheites (was die Vorteile der DB ausnutzt) hinbekome.

Außerdem muss ich wie gesagt die Klassen die die Infos aufnehmen so oder so implementieren so dass ich nur deren Verwaltung (die ich mir nicht soooo schwer vorstelle) extra machen muss im Gegensatz zur DB-Lösung. Und wie schon erwähnt fühlt sich ein eigenes Objekt irgenwie "echter" an als eine Abfrage an die DB.

Aber trotzdem danke für die vielen gutgemeinten Vorschläge und Hinweise. Ein wenig klarer ist das Bild geworden.

Gruß
Despotist

Despotist hat geschrieben:Außerdem muss ich wie gesagt die Klassen die die Infos aufnehmen so oder so implementieren so dass ich nur deren Verwaltung (die ich mir nicht soooo schwer vorstelle) extra machen muss im Gegensatz zur DB-Lösung. Und wie schon erwähnt fühlt sich ein eigenes Objekt irgenwie "echter" an als eine Abfrage an die DB.

Nur so am Rande, genau das macht ja die Bibliothek die ich da verlinkt habe (NHilbernate)... So müsstest du dich also mit noch weniger Serialisierung befassen als du es jetzt tuen müsstest. Du musst für jede Klasse, der Instanzen in die Datenbank persistiert werden sollen, lediglich eine Mapping XML schreiben...

Aber ich denke auch, dass du da eher auf deine innere Stimme hören solltest...

Ist nur ein Beispiel, aber so sieht sowas aus.

code mapping

Also so richtig passend kann man nur was sagen, wenn man alle Details im Kopf hat, aber ausm Bauch raus würde ich jeder Fraktion einfach eine Liste mit ihrem Wissen geben. Darin enthalten sind Referenzen auf alle bekannten Objekte. Ggf mit nem Filter dabei, wenn man von einem Objekt nur einen Teil kennen kann. Und bei Bedarf mehrere Listen, wenn es nach Kategorien wie Rohstoffe, etc streng getrennt betrachtet wird. Das würde ich dann geordnet in die Liste packen und zwar anhand einer Relevanz sortieren,so dass die besten Einträge oben sind. Die Bewertungsfunktion dafür muss dann eben alles enthalten, was du brauchst. Ziel ist es eigentlich, das ganze Wissen so zu strukturieren, dass die wirklich wichtigen Dinge oben sind, und man den Rest ignorieren kann. Wenn ich z.B. Wissen über Rohstoffe verwalte, dann kenne ich vielleicht x Planeten mit irgendwas drauf. Manche gehören mir schon, das ist wenig wichtig. Manche sind weit weg, manche gehören einem starken Feind. Interessant sind doch nur die reichen Vorkommen die nah dran sind die ich gut in mein Reich eingliedern kann und die nicht zu stark verteidigt sind, falls überhaupt. Wenn das so geordnet verwaltet wird, dann muss sich die KI nur die ersten 3 - 5 Referenzen ansehen und dann entscheiden, was sie damit tut. Und vielleihcht 50 andere Planeten mit Rohstoffen werden einfach gar nicht beachtet, weil sie schon vorher aussortiert wurden. Die Bewertung und Ordnung muss man dann halt immer mal neu organisieren.

Manchmal kann es helfen, wenn man anders herum denkt. Ich habe z.B. mal über die Sims gelesen, dass nicht die Sims nach Essen suchen, sondern das Essen ruft nach den Sims. Ein Kühlschrank sendet als in einem bestimmten Radius "bei mir gibts Essen". Ein Sim erhält alle Reize seiner Umgebung, und reagiert darauf. Der Vorteil ist eben, dass der hungrige Sim nicht nach dem Essen suchen muss, sondern das Essen meldet sich beim Sim.

Vielleicht kannst du auch eine Lösung finden, wenn du etwas anders herum auf ziehst. Die Frage ist vielleicht gar nicht, was weiß deine Fraktion alles, sondern was will deine Fraktion erreichen, und dann erst, welches Wissen dazu ist erforderlich. Unter der Haube sind die Mechaniken manchmal einfacher als man denkt. Die KI muss gar nicht super alles kennen. Sie muss eigentlich nur sinnvoll handeln. Das kann man oft mit deutlich weniger Aufwand simulieren.

-JAW

Also, hab jetzt nicht alle Antworten gelesen, und es kann sein das es schon gesagt wurde, aber muss was zum Thema Datenbanken loswerden.

Finde Datenbanken in Spielen immer gut :D vor allem wenn du große Datenmengen verwalten willst.
Und weil du meinst dir fehlt die Kontrolle wenn du Datenbanken benutzt.
Du benutzt die Datenbank ja nur zum speichern deiner Daten. Im Code werden (würden bei mir z.B.) ja ein paar Klassen (Bäume?) laufen die den ganzen Input der Datenbanken aufnehmen, prüfen, verwalten und bearbeiten. Also denk ich mal das die "Kontrolle" ganz am Design deines Codes liegt... wie gesagt, du benutzt die DB('s) ja nur zum speichern von Daten, was zur Laufzeit damit passiert entscheidet dein Programm. Würde ich jetzt von mir ausgehen, würde ich sowieso keine SQL, Oralce, whatever Datenbank benutzen, sondern ein eigenes durchdachtes System wie ich meine Daten in Klassen organisiere, und diese dann als "Datenbank" auf meine Festplatte schreibe/von meiner Festplatte lade.

so, meine Gedankengänge zu diesem Thema auch losgeworden :mrgreen: