Entwickler-Ecke

Programmierwerkzeuge - Datenbank oder xml file


jackle32 - Di 05.02.08 12:55
Titel: Datenbank oder xml file
Hallo,

ich habe mal eine ganz grundsätzliche Frage. Ich bin gerade dabei ein Konzept für ein Programm zu entwerfen, dass ich schon lange mal programmieren wollte. Dabei handelt es sich um ein Spiel, das an ein altes Gameboy spiel erinnern soll.
Dabei soll es in der späteren Version einige Level (ca. 200 oder mehr) geben, die zu meistern sind. Für jedes Level muss ich mehrere Daten speichern. Dies werden so etwa 20 Integerwerte und 1 oder 2 Booleans sein.

Jetzt meine Frage, wie verwalte ich diese am einfachsten. Ist es sinnvoll dafür schon eine Datenbank anzulegen oder recht auch eine xml Datei aus? Möchte immer mehrere Levels zusammen packen und es so auch erweiterbar halten. Wer hat damit Erfahrungen? Vielleicht auch schon in der Hinsicht der Manipuliersicherheit.

Gruß Jack


P.S. hoffe bin in der richtigen Sparte war mir da nicht so ganz sicher


Yogu - Di 05.02.08 14:45

Von einer Datenbank würde ich abraten, da die meisten einen Server auf dem Rechner erfordern. Du kannst von den Game-Nutzern nicht verlangen, dass sie einen solchen installieren.

Ein weiterer Nachteil ist, dass Datenbanken anders aufgebaut sind, als du es es normalerweise für Spiellevels brauchst. Oder willst du nur Spielstände speichern? Dann wäre von der Übersichtlichkeit eine DB wohl besser.

Erweitern kannst du XMLs besser, weil da einfach nur eine Datei heruntergeladen werden muss, in der Datenbank muss erst noch eine Verbindung aufgebaut werden etc.

In Sachen Sicherheit kenne ich mich da nicht so aus, aber ist dass denn bei einem Spiel notwendig? Ich meine, solange du keine Preise aussetzt o. ä. dann ist der User doch selber schuld, wenn er cheatet !?


jackle32 - Di 05.02.08 15:02

Okay das mit dem Server wusste ich net, da hast du recht das lässt die DB schon ausscheiden.

Zu den Daten, dort werden die eigentlichen Spieldaten gespeichert, dabei handelt es sich um ein Spielfeld mit 15x15 Feldern. Die müssen vorbelegt werden, das sind 15 der integer Werte. Des weiteren werden Bestzeiten, Versuche ob schon bestanden und so weiter gespeichert. also schon so eine Art Spielstand.

Kennst du dich vielleicht mit xml dateien genauer aus, vor allem wegen der Datengröße und darauß resultierenden Zugriffszeiten?

Gruß Jack


Kroko - Di 05.02.08 15:06

ja man kann auch Db nehmen, zBSp MyBase, siehe hier [http://www.delphi-treff.de/tutorials/datenbank-tutorials/win32/einfache-datenbanken-mit-mybase/katalog/147/]


Yogu - Di 05.02.08 15:37

user profile iconjackle32 hat folgendes geschrieben:
dabei handelt es sich um ein Spielfeld mit 15x15 Feldern. Die müssen vorbelegt werden, das sind 15 der integer Werte.

Warum sind 15x15 Felder 15 Werte? Ich denke da eher an 225 :gruebel:

Aber das ist auch immer noch klein. Wahrscheinlich kannst du sogar Bytes nehmen, oder wenn es sein muss, Words. Da die Datei nicht mal die KB-Grenze übersteigt, würde ich sagen, die Zugriffszeit wäre ein paar Millisekunden. Darum musst du dir da keine Gedanken machen. Die enzelnen Levels solltest du in verschiedene Dateien packen, auch wegen Updates etc.

Ein kleiner Tipp: Speichere die Spielstände nich in den Level-Dateien. Dann kannst du die Scores auch mal schnell ins Netz übertragen. Du hast einfach eine bessere Übersicht, was jetzt konstant ist, und was verändert werden kann.


jackle32 - Di 05.02.08 15:56

Es sind deshalb 15 Werte, da ich immer eine Zeile in einem Integerwert abspeichern Werte, da jedes Feld nur 0 oder 1 sein kann. Ich will nämlich nicht 225 boolean werte speichern müssen. daher sind 15x15 Felder gleich 15 zahlen im speicher.

Ich wollte eben nicht die einzelnen Level in einzelen dateien stecken, da sich so die Anzahl der Datein sehr hoch werden würde. Dachte ehr daran die einzelnen abschnitte (voraussichtlich 4) als einzelen Dateien zu machen, in diesen wären dann ca. 70 Level enthalten, daher dachte ich an das Problem mit den Zugriffszeiten.

Denke aber ich werd jetzt dann mit einer xml Datei machen, der ich eine andere Endung verpasse, damit es nicht ganz so offentsichtlich ist, wie man die Ändern kann.

Gruß Jack


Kroko - Di 05.02.08 16:56

user profile iconjackle32 hat folgendes geschrieben:
...

Denke aber ich werd jetzt dann mit einer xml Datei machen, der ich eine andere Endung verpasse, damit es nicht ganz so offentsichtlich ist, wie man die Ändern kann.

Gruß Jack
Ha Ha, selten so gut gelacht :lol:


Yogu - Di 05.02.08 17:00

Nochmal wegen den Zugriffszeiten: Rechnen wir mal hoch...

1 Level besteht aus 15 Zeilen zu je 15 Kästchen.
Also 15 Bit pro Zeile => Word reicht.
1 Level besteht also aus 15 Words.
Also 15x2 = 30 Byte.

Diese 30 Byte würde ich einfach hintereinander hängen. Also ein String mit 30 Byte pro Level.


XML-Daten
1:
2:
3:
4:
5:
6:
7:
<file version="1.0">
<level id="1" content="******************************" />
<level id="2" content="******************************" />
<level id="3" content="******************************" />
<level id="4" content="******************************" />
<level id="5" content="******************************" />
</file>

So in der Art könnte deine Leveldatei aussehen.

Ca. 60 Byte pro Level
60*70=4200 Byte pro Abschnitt
Also wesentlich weniger als 5 KB pro Datei.

Das müsste noch zu schaffen sein. Ich denke, da gibt es keine Probleme.


DrRzf - Mi 06.02.08 04:51

Die nächste möglichkeit wäre ein record, und diesen in ein Dynamisches array packen.
hätte die möglichkeit, dass du damit bereits intern fix auf die daten zugreifen kannst, und die sind auch recht einfach und schnell zu speichern.


Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
Type
  TLevel = record
    LevelName : string[20];
    Spielfeld : array[1..15of integer;
    //evtl noch zusätzliche definitionen
  end;

var
  LevelDA : array of TLevel; //DatenArray aller levels

procedure AddLevel(Level : TLevel); 
var
  l : integer;
begin
  l := length(LevelDA);
  setlength(LevelDA,l + 1);
  LevelDA[l] := Level;
end;

procedure SaveLevels;
var
  fw : file of TLevel;
  i,l : integer;
begin
  l := length(LevelDA);
  assignfile(fw,'Levels1.lev');
  try
    rewrite(fw);
    for i := 0 to l - 1 do
      write(fw,LevelDA[i]);
  finally
    CloseFile(fw);
  end;
end;

procedure LoadRang;
var
  fw : file of TLevel;
  i : integer;
begin
  if FileExists('Levels1.lev'then
    begin
    assignfile(fw,'Levels1.lev');
      try
        reset(fw);
        i := 0;
        while not Eof(fw) do
          begin
          SetLength(LevelDA,i + 1);
          Read(fw,LevelDA[i]);
          i := i + 1;
          end;
      finally
        CloseFile(fw);
      end;
    end
  else
    ShowMessage('Levels1.lev' nicht gefunden');
end;


_frank_ - Mi 06.02.08 05:26

willst du delphi 1-7 verwenden? mir ist z.b. keine funktionierende XML-Komponente für Delphi<5 bekannt, hab selbst schon verzweifelt für d3 gesucht ;( die vorhandenen bauen auf techniken auf, die neuere delphiversionen benötigen (dynArrays, overload, ...)

betreffs der manipulierbarkeit...speichere doch eine prüfsumme (md5,crc,..., was eigenes) mit in der Datei, dann kannst den Wert verifizieren.

Datenbank halte ich auch für ungeeignet, evtl. noch mittels Tfilestream eine byte-folge speichern, ein bestimmtes byte nimmst dann halt als Leveltrenner, bzw. wenn die level immer gleich sind und bleiben brauchst dann einfach nur an die position

Delphi-Quelltext
1:
(level-1)*levelsize                    

zu-seek-en ;) und per

Delphi-Quelltext
1:
read(@buf,levelsize)                    

die bytes z.b. in ein

Delphi-Quelltext
1:
array[1..levelsize] of byte                    

einlesen
evtl. noch einen header einbauen, der die anzahl und größe der levels definiert, somit hast du dann ein variables format...

4 bytes größe vom header (startpunkt der leveldaten)
1 byte levelanzahl
1 byte größe level1
1 byte größe level2
...

rechnest dann einfach die levelgrößen, um an den offset des nächsten levels zu kommen.

HTH Frank