weitergabe und Speicherung von daten

[jfheins]

Zitat von blinder007:

Würde für dateien die in xml erstellt wurden Punkt c zu treffen oder nicht?

Nein. XML Dateien sind entwickelt worden, um das Datenschema (also was wo steht) explizit mit den Daten zusammen zu speichern.
Einstellungen sehen dann z.B. so aus:

Code:

<?xml version="1.0" encoding="utf-8"?>
<Param xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Kappa>6.7e-6</Kappa>
  <b1>0.1</b1>
  <b2>0.6</b2>
  <Lambda>33.63</Lambda>
  <Epsilon>0.25</Epsilon>
  <Hm>2.75e5</Hm>
  <w0>13.186e-6</w0>
</Param>

Du siehst, man kann da relativ einfach dran herum fummeln. Abhilfe wäre z.B. die Datei nicht "*.xml" zu nennen, sondern eine eigene Endung oder "*.dat". Und vielleicht im Appdata-Ordner speichern, da verirren sich nicht so viele Benutzer hin.

Mit ein Grund für XML ist ja, dass die Daten wichtiger als das Programm sind. Man hatte häufiger mal "uralte Daten, aber verflucht das Programm läuft nicht mehr. Wir brauchen aber die Daten!!!"

[blinder007]

das klingt interessant, sprich ich speichere meine dateien als xml-files... werde ich mal drüber nachdenken und schauen was hier mit meiner delphi 6 so geht. beim lesen des oben geposteten threads überlegte ich jetzt doch tfilestream zu verwenden, aber da treten dann doch wohl einige Fehler auf.
Was mich dann noch interessieren würde: angenommen ich speichere die records oder klassen in einer xml-file. wie kann ich diese, in der Laufzeit, renamen und delphi zeigen, um welches format es sich handelt, um dann entsprechend damit umzugehen?
Sprich: ich ändere den Dateitypen in .eem (fiktives dateiformat, der user soll es einfach nicht erkennen können), wie kann delphi das als xml-file identifizieren?

[Furtbichler]

Eine Datei umzubenennen, damit die Inhalte nicht verändert werden, ist in etwa so schlau, wie das Schild, auf dem 'Bank' steht, mit einem selbstgeschriebenen Zettel 'keine' zu versehen.

So gut wie jeder wird die Datei nehmen, und mal mit Notepad öffnen. Ich mache das jedenfalls mit jeder mir unbekannten Datei (bzw. Notepad++).

Wie wäre es mit einer einfachen Datenbank, z.B. Firebird? Das zu verändern, dürfte nur mit FB selbst möglich sein und wenn man den Zugriff mit einem Kennwort sichert, wird es noch schwieriger. Unmöglich ist gar nichts, und insofern ist das auch keine perfekte Lösung.

Eine Frage: Darf der Anwender die Dateien nicht verändern, oder willst Du nur mitbekommen, *wenn* er sie verändert hat?

[Der schöne Günther]

Der XML-Inhalt ist im Endeffekt ein langer String. Du kannst die Datei ganz normal mit z.B. einem TFileStream öffnen und auslesen. Für Delphi gibt es mehrere XML-Libriaries. Ich benutze XML exzessiv für Speicherung von Konfigurationen und Interprozess-Kommunikation und bin mit dem normalen MS-XML (Klassen IXMLDocument, IXMLNode usw. aus den Units XmlIntf, XmlDoc, ...) eigentlich immer sehr gut gefahren. Ich habe gerade kein Delphi offen, aber die Klasse IXMLDocument hat mein ich bereits eine Methode LoadFromFile , da hast du es dann direkt drin, die Dateiendung ist dabei ziemlich egal.

Ob Delphi 6 MSXML schon kennt weiß ich nicht. Vielleicht solltest du die Info in dein Profil eintragen, so sieht man immer, mit welcher Version derjenige unterwegs ist.


@Furtbichler: Die Metapher sehe ich genauso. Nur bei der Häufigkeit, wie oft jemand anfängt in Dateien von Programmen zu wühlen nicht. Wir wissen nicht, was das genau für eine Software ist. Werden damit Waren hergestellt wird früher oder später jemand darin wühlen. Ist es ein Freeware oder in-house Tool für irgendeine Verwaltung oder Visualisierung, dann sicher weniger.
Ich frage mich halt wirklich, ob es denn schlimm ist, wenn jemand das verändert. Wenn er sich damit etwas zerschießt weiß er, dass er selber schuld ist.

Blöd wird die Sache erst, wenn der Kunde dann anruft "Hey, euer Kram funktioniert auf einmal nicht mehr!" obwohl er ihn selbst kaputt gemacht hat. So etwas gibt zu Genüge.

Zitat:

Eine Frage: Darf der Anwender die Dateien nicht verändern, oder willst Du nur mitbekommen, *wenn* er sie verändert hat?

Gute Idee!

[blinder007]

ok, dann hier weitere informationen
es handelt es sich um ein, zunächst freeware, später auch shareware, spiel.

In meinem Spiel gibt es auf einer Karte unterschiedliche Städte. Ich will zwei Dateien haben.
Datei 1: enthält die größe der Stadt, die Anzahl der Objekte und Zahlen die diese Objekte identifizierbar machen. in der zweiten datei finden sich dann die ganzen identifizierer, denen dann weitere eigenschaften zugeordnet werden können.

Der User soll nicht in der Lage sein zu erkennen, was sich wo verbirgt oder welche Eigenschaften es hat. gelegentlich soll ein Objekt in einer Stadt zerstört werden, dafür muss aber nicht zwangsläufig der Wert gelöscht werden.
Ist das Prinzip klar?

[Furtbichler]

Dann bleibt nur noch Verschlüsseln. Aber das ist auch Bockmist, weil man das mit Reverseengineering knacken kann.

[Der schöne Günther]

Aaah, also praktisch eine Karte.

Wenn ich mir die ganzen Spiele anschaue, die über Jahre hinweg erfolgreich waren und sind - Dann konnte der Benutzer immer selbst auch verändern und neues erschaffen. Also eine ganz statische Speicherung im Quelltext haben wir hier wohl vom Tisch.

Wie willst du dann Spielstände organisieren? Ich hätte spontan gedacht, dass ein Spielstand dann ebenso wieder solch eine Karte ist - Wenn beispielsweise etwas zerstört wurde, sich bewegt hat, was auch immer.

Es läuft komplett lokal oder ist es ein Mehrspieler-Spiel? Bei Spielern haben wir wohl eher die Tendenz, dass jemand in den konkreten Dateien wühlt. Ein Spieler ist neugierig

Ich würde zwar immer noch abwiegen ob man es denn wirklich künstlich unterbinden sollte. Aber: Wenn man es auch nicht lesen können soll, reicht dann nicht, um 95% der potentiellen "Cheater" abzudecken eine billige Caesar-Chiffrierung wie ROTx? Wäre ja technisch für das Einlesen und Speichern in ein paar Minuten abgefrühstückt.

[BUG]

Zitat von blinder007:

es handelt es sich um ein, zunächst freeware, später auch shareware, spiel.

Spieler sind natürlich etwas versierter, denen könnte man auch zutrauen, einen SQLite-Editor oder einen Hex-Editor zu benutzen.
Solange das ein Singleplayerspiel ist, ist das imho aber nicht so tragisch.

An deiner Stelle würde ich mir SQLite auf jeden Fall mal anschauen; eventuell kannst du einige Sachen, die du mit den Daten vorhast, sogar in SQL erschlagen.

Zitat von blinder007:

Datei 1: enthält die größe der Stadt, die Anzahl der Objekte und Zahlen die diese Objekte identifizierbar machen. in der zweiten datei finden sich dann die ganzen identifizierer, denen dann weitere eigenschaften zugeordnet werden können.

Das riecht doch schon ein bisschen nach relationaler Datenbank

Zitat von jfheins:

Mit ein Grund für XML ist ja, dass die Daten wichtiger als das Programm sind. Man hatte häufiger mal "uralte Daten, aber verflucht das Programm läuft nicht mehr. Wir brauchen aber die Daten!!!"

Das ist ein wichtiger Punkt. Wenn dein Programm die Daten nur ließt, kannst du die Daten in einem beliebig bekloppten Format ausliefern, solange du die Daten in einem gut dokumentierten Format bei dir gespeichert hast.

[blinder007]

wenn ich die sämtlichen spielstände und oder karten in typisierten dateien oder in "einem beliebig beklopten format" abspeichere, also über tfilestream, dürfte ich dann nicht schon ein großteil der Spieler abschrecken, weil sie nicht wissen, was sie vor sich haben? Wenn ich dann die records noch vor dem einspeichern schifriere, dürfte doch 99% aller Spieler ein Bein gestellt sein. Übrigens ist es single player, zunächst zumindestens

edit: was sind relationale Datenbanken?

[Der schöne Günther]

Zitat von blinder007:

dürfte ich dann nicht schon ein großteil der Spieler abschrecken?

Ich glaube nicht nur die Spieler, auch einen Großteil der Entwickler

Spaß beiseite. Ich weiß nicht, wie sehr die Zeit drängt, aber ich persönlich würde mir - für das reine Lesen und Speichern der Daten - mindestens zwei kompatible Ansätze bauen. Einmal ein menschenlesbares Format mit dem du als Entwickler komfortabel arbeiten und prüfen kannst. Ich glaube es macht keinen Spaß in einer langen Bytewurst einen Fehler zu suchen wenn das Programm nicht das tut, was es soll.

Wenn es dann in die Veröffentlichung geht kannst du doch einfach das XML Lesen/Speichern gegen Bytewurst-Lesen/Schreiben tauschen ohne dass der Rest des Programms beinflusst wird. Das wäre jetzt mein Geschmack gewesen.