Jaki jest dobry format pliku do zapisywania danych gry? [Zamknięte]

Muszę zapisać niektóre niestandardowe dane gry. Mapa, odtwarzacz itp.

Wszystkie będą miały „obiekty podrzędne”. Na przykład mapa i mapa będą miały „tablicę” kafelków. tj. dane hierarchiczne. Mam nadzieję, że nic binarnego.

Jaki byłby dla nich dobry format?

Do tej pory rozważałem:

Serailizacja: To jest SZYBKIE i łatwe, ale ma tendencję do pękania , gdy zmieniam podstawowe klasy :(

XML: Naprawdę nienawidzę analizować tego. Mój przypadek testowy zawierał ponad 100 wierszy kodu i wydawał się lubić mnóstwo „pracowitej pracy” dla nawet bardzo prostego formatu.

INI: byłoby naprawdę niezręczne w przypadku danych hierarchicznych.

Protobuf: Nigdy go nie używałam , ale przeczytaj, że musisz zrobić wiele ręcznego mulczowania i psuje się, jeśli zmienisz klasę.

Inne opcje? Dlatego tu jestem!

Edycja: to jest Java Btw.

Edycja 2:

Zdecydowałem się na „kontrolowaną serializację binarną” (patrz poniżej).

Plusy:

• to jest szybkie

• jest mały (na dysku) i może być łatwo skompresowany / zdekompresowany podczas odczytu / zapisu.

• jest bardzo łatwy do odczytu / zapisu z gry i zestawu narzędzi.

• Potrafię zdecydować, co włączyć / wyłączyć obiekt.

• Obiekty / dane można zagnieżdżać.

Cons:

• Nie można go edytować ręcznie (np. XML, YAML itp.)

• Nie można go łatwo odczytać / zmodyfikować za pomocą skryptów

• Serializacja Java domyślnie jest dość powolna / rozdęta w porównaniu z innymi implantacjami, ale jest stabilna i działa

Aby wyświetlić dane hierachiczne, dobrym rozwiązaniem byłyby YAML lub JSON . Są znacznie prostsze i łatwiejsze do analizy niż XML.

Inną opcją byłby „kontrolowany” proces serializacji binarnej. Każdy obiekt zapisuje swój stan w kontrolowany sposób, tj

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

id Tech 4 (silnik Quake 4 / Doom 3) stosuje takie podejście.

Dobrze wykonany format binarny ma naprawdę wszystkie zalety, jest szybki, stosunkowo mały i tak elastyczny, jak go stworzysz.

Tworząc format binarny nie obowiązują żadne reguły, co jest wielką zaletą, ale jak na ironię to w dużej mierze spowodowało, że struktury plików binarnych mają złą nazwę. XML, JSON i tym podobne podejmują za Ciebie wiele decyzji, są dalekie od zawsze optymalnych, ale są dość bezpiecznymi wyborami, które zwykle pomogą ci uniknąć niektórych typowych problemów.

Zidentyfikuj te problemy, zaprojektuj swój format z myślą o nich i możesz stworzyć świetny format binarny.

Jeśli nie masz wystarczającego doświadczenia / pewności, aby utworzyć format binarny, a ilość danych jest na tyle mała, że ​​wpływ prędkości będzie znikomy, sugeruję, abyś używał JSON, to proste, ale spełnia swoje zadanie.

Wybór formatu pliku zależy w dużej mierze od bieżącego zestawu narzędzi i gry, którą zamierzasz stworzyć. Powiedziawszy to ...

Zestaw narzędzi jest jednym z najważniejszych czynników przy podejmowaniu decyzji o formacie pliku gry. Jeśli tworzysz format binarny , musisz zawsze upewnić się, że masz narzędzia do wprowadzania danych gry. Może to być tak proste jak edytor szesnastkowy lub tak złożone jak Unreal Editor.

Myślę, że główną zaletą plików XML, YAML lub innych plików językowych jest to, że można je łatwo edytować za pomocą edytora tekstu. A przy użyciu istniejącego standardu gwarantuje, że nie możesz się pomylić . Ale to jest bardzo nudne, gdy masz tysiąc plików, co prowadzi mnie do następnego punktu.

Gra. Jaką grę tworzysz? Dlaczego mówię, że wpłynie to na format pliku? Ponieważ jeśli robisz coś takiego jak bombowiec 2D, możesz uciec od prostego pliku tekstowego, takiego jak:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

Innymi słowy, zawsze wybieraj najbardziej oczywisty format dla swoich danych . Gry RPG to najbardziej złożony gatunek gier. Wymagają dużej ilości danych. Ale nie oznacza to, że musisz trzymać określony format , zarówno binarny, jak i tekstowy dla wszystkich danych w grze.

• Mapy, cząstki i inne elementy graficzne zwykle używają niestandardowego formatu binarnego. Ponieważ jest to najprostszy sposób na jego wdrożenie . Opisywanie tekstów mapami nie jest po ludzku rozsądne. Zwykle edytowane za pomocą edytorów map / poziomów / cząstek.
• Gracze, przedmioty, wrogowie, umiejętności i zadania to statystyki wpływające na równowagę gry . Zazwyczaj wymagają one wielu nakładów i poprawek. Lubię to robić, umieszczając go w pliku XML w celu ułatwienia implementacji, ale mając edytor obiektów do zabawy dla projektantów. Najlepsze z obu światów .

Zasadniczo chcesz opisywać tekst w formacie tekstowym, a grafikę w formacie binarnym. Poniższy przykład powinien dać ci przykład:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

Podsumowując, według mojej pełnej rekomendacji, jeśli to możliwe, nie skryptuj swoich danych, chyba że jest to absolutnie konieczne . Użytkownik końcowy nie dba o to, jak niesamowity jest ten format, dopóki gra jest dostępna, tylko to się liczy.

Pozdrawiam, Roy =)

BSON jest całkiem niezły. http://bsonspec.org/ . Łatwiej jest parsować niż JSON i lepiej zawiera dane binarne, ale nadal ma ładną strukturę. Jest nieco podobny do buforów protokołów. Minusem jest to, że wydaje się, że nie ma dużego wsparcia dla narzędzi poza mongodb.

EDYCJA: MsgPack ( http://msgpack.org/ ) jest również podobny do BSON i wydaje się, że zyskuje większą przyczepność.

Co się stało z niestandardowym formatem danych binarnych? Jeśli boisz się surowej serializacji, napisz własny system, który zapisuje pola w razie potrzeby i odczytuje je z powrotem. Nie ma potrzeby używania xml, który jest naprawdę zbyt obszerny i skomplikowany w sytuacjach, w których nie potrzebujesz przejrzystości zapewnianej przez ten format. Po prostu zdefiniuj dobrze określony format pliku i trzymaj się go, pozostawiając trochę miejsca na rozszerzenie zestawu danych w każdym rekordzie, wypełniając je wartościami zerowymi (powiedz, że masz teraz rekord 100 bajtów, a następnie wypełnij go do 150 do przyszłego użytku.
Dodaj numer wersji i być może sumę kontrolną, abyś wiedział, które pola powinny zostać wypełnione, i sprawdź poprawność pod względem ważności, i możesz już iść.

Możesz łączyć XML lub inny format z wstawkami Base64 dla niektórych określonych danych, a dla pól wymagających czytelności możesz użyć zwykłego TEKSTU