Platzsparende Alternative zu .txt-Dateien

[Faberix]

Hallo

Ich suche ein passendes Dateiformat um Levels für mein Jump and Run zu speichern. Im Moment benutze ich Textdateien, aber die fressen ziemlich viel Speicherplatz und ich will die Anwendung möglichst klein halten.

Die Level-Textdateien sind wie folgt aufgebaut:
[Abkürzung für das Objekt]:[x],[y],[optionale zusätzliche Parameter]

Das Dateiformat sollte auch auf Android lesbar sein, da ich später eine Android-Version des Spiels programmieren will.

Danke im Voraus für die Antworten
MFG, Faberix

 

[Major_Sauce]

Txt-Dateien sollten normalerweise nicht all zu groß sein, du solltest dir auf jeden Fall Methoden anschauen wie man Maps verpacken kann.
Da gibt es so ziemlich viele platzsparende Möglichkeiten. (Zumindest bei bestimmten "Map-Arten".

mfg Major_Sauce

 

[MrTroble]

Es wer auch möglich jede txt nochmal in eine zip zu packen und nur zu decompilen wenn man sie braucht

 

[InfectedBytes]

Falls du die die einzelnen Einträge als Strings formatiert in die Datei schreibst, könntest du dir überlegen ein Binärformat zu nutzen.
Dann kann man die Textdateien zwar nicht mehr in einem einfachen Texteditor lesen, aber dafür sparst du halt platz.

Falls deine "Abkürzung für das Objekt" ein String ist, könntest du diesen auch noch durch eine ID ersetzen (ob short oder int hängt davon ab wieviele IDs du benötigst)

 

[RalleYTN]

du kannst deine x und y koordinaten in einem ASCII buchstaben speichern, dass machst du mit (char)x.
wenn x jetzt 34 wäre, dann würde in der Datei " stehen. wenn du viele x und y koordinaten hast, dann sollte das extrem viel platz sparen.

 

[CSHW89]

Wie groß sind denn die Levels so durchschnittlich, und wie viele Objekte sind pro Level vorhanden. Vor allem auf das Verhältnis kommt es an. Sagen wir b ist die Breite und l ist die Länge des Levels. Wenn die Anzahl der Objekte sehr hoch ist, also nah an b*l, dann sollte man eine andere Speicherart versuchen. Statt immer ObjektID,x,y zu speichern, kann man die Koordinaten weglassen, indem man der Reihe nach nur die ObjektID speichert. Also ObjektID_an_0_0, ObjektID_an_0_1, ObjektID_an_0_2 usw. bis ObjektID_an_b_l. Dann gibts noch ne spezielle ObjektID für "kein Objekt". Zusätzlich kann man dann die ID binär speichern, wie es meine Vorredner bereits erklärt haben.

lg Kevin

 

[Faberix]

Die Levels haben normalerweise eine Breite von 50000 Pixeln. Für jeden soliden Pixel und jede Entity wird ein Eintrag gemacht. Es sind also ziemlich grosse Textdateien. Früher speicherte ich die Levels als PNG, es ging allerdings sehr lange, bis ein Level geladen war. Wenn ich also die Methode von CSHW89 anwenden würde, hätte mein Spiel wieder zu lange Ladezeiten, da ja jeder einzelne Pixel vermerkt werden müsste. Wahrscheinlich würde die Datei wegen der vielen zusätzlichen Einträgen eher grösser werden als kleiner.

@RalleYTN: Für die Levelbreite reichen die ASCII-Zeichen leider nicht.
@Major_Sauce: Kannst du ein Beispiel für ein Map-Dateiformat machen? Man sollte nicht jeden einzelnen Pixel durchgehen müssen.
@InfectedBytes: IDs für die Objektarten ist eine gute Idee. Mit Binärformaten kenne ich mich leider nicht so aus, könnte mir das jemand erklären oder einen Link zu einem guten Tutorial geben?
@MrTrouble: Es wäre etwas umständlich, jede einzelne Datei in eine eigene Zip-Datei zu packen, aber ich könnte mir überlegen, den ganzen Levelordner in ein Zip zu packen, allerdings nur, wenn es keine bessere Lösung gibt.

Ich habe gerade gemerkt, dass die Dateien in der jar komprimiert werden. Weiss jemand, ob die Dateien bei einer Android-App auch komprimiert werden?

mfg, Faberix

 

[InfectedBytes]

Für jeden soliden Pixel machst du einen Eintrag? Ist das denn nötig?
Wenn ich jetzt mal von einem "normalen" Jump&Run ausgehe, besteht jedes Level aus verschiedenen Balken (auf die man Springen kann) und verschiedene Gegner.
In so einem Fall würde man einfach nur Position + Ausmaße der Balken, sowie Position und Typ der Gegner speichern.

Kann sein das ich dich falsch verstanden habe, aber für mich klingt es so, dass du jeden Pixel eines Balkens in der textdatei speicherst, das ist natürlich extrem verschwenderisch.

 

[Faberix]

Du hast mich falsch verstanden
Ich speichere nur den obersten und den untersten Pixel für jede X-Koordinate der Balkens. Das ermöglicht es mir, die Levels frei zu zeichnen und somit habe ich so viel mehr Spielraum beim Leveldesign.

 

[InfectedBytes]

Ok, schon etwas besser^^
Aber auch das ist noch etwas ineffizient. Für einen 100 Pixel langen Balken benötigst du auch hier schon 200 Einträge. Vermutlich hat ein Balken auch mal längere gerade Abschnitte. Wenn dem so ist, kannst du einen Balken auch einfach als Polygon auffassen.
D.h. du speicherst nur die signifikanten Punkte, welche anschließend mit Linien verbunden werden.

Außerdem ist die Frage ob du diesen Spielraum überhaupt benötigst. Vielleicht reichen dir ja auch einfach 20 verschiedene Balken.
In einer Datei speicherst du dann diese 20 verschiedenen Balken (zusammen mit eindeutigen IDs) ab und in deiner Leveldatei speicherst du nur Position und ID des zu nutzenden Balkens.

 

[Faberix]

Ich denke, auch wenn ich den Spielraum nicht ganz ausnütze, bin ich immer noch schneller beim Level erstellen, wenn ich einfach frei zeichnen kann, weil ich dann nicht so viel das Tool wechseln muss. Das mit den geraden Strecken werde ich mir mal überlegen. Falls die Levels in Android-Apps sowieso komprimiert werden hat sich das Problem erledigt, denn dann macht es ja nicht mehr so viel aus, wie viele Zeichen die Textdatei enthält.

 

[RalleYTN]

Du könntest auch 5000 ID's lange ketten in eine zeile packen. So hätte jede ID beispielsweise 3 oder 4 zeichen. Alles in der obersten zeile hat die y koordinate 0 und jeder 3 oder 4 zeichenblock in der zeile hätte dann die entsprechende x koordinate. Ich werde mal ein beispiel programmieren und es später verlinken.

 

[RalleYTN]

Hier ist mein Beispiel: Platzsparende Level Dateien
Ist'n eclipse projekt