Czy lepiej byłoby używać XML / JSON / Text lub bazy danych do przechowywania zawartości gry?

Zastanawiam się, jak zaimplementować grę opartą na komponentach, ponieważ wydaje się to być najgorętsze i podoba mi się pomysł takiego elastycznego projektu. Jedną z cech takiego projektu jest to, że dodawanie nowych rzeczy do gry może odbywać się za pomocą danych, często przedstawianych jako ładowanie treści za pomocą plików tekstowych, takich jak XML. Ma to tę zaletę, że jest czytelne dla człowieka i łatwe do edycji w dowolnym edytorze tekstu. Z drugiej strony, tekst może być wolniejszy, a Ty musisz zarządzać dużą kolekcją plików danych. Podobne formaty tekstowe, takie jak JSON lub pliki konfiguracyjne, miałyby podobne zalety.

Z drugiej strony istnieją małe, przenośne bazy danych, takie jak SQLite lub Tokyo Cabinet. Pliki te, choć nie są bezpośrednio czytelne dla człowieka, są łatwe w obsłudze i wyobrażam sobie, że do projektowania treści gier i tak byłoby lepsze narzędzie do edycji. Korzystanie z bazy danych pozwala na spójne przechowywanie informacji o konfiguracji i łatwe wyszukiwanie. Możesz również serializować dane do bazy danych, aby zapisać gry.

Pod względem wydajności, myślę, że ogólnie XML jest szybszy dla małych plików, ale baza danych lepiej skaluje się do dużych ilości danych. Wyobrażam sobie, że w każdej prawdziwej grze będzie mnóstwo przedmiotów.

Pytanie: które podejście jest lepsze? Opieram się na DB, ale chcę wiedzieć, czy istnieją ukryte pułapki lub naprawdę silne zalety plików tekstowych. Lub jeśli istnieją inne alternatywy poza nimi (chyba serializacje do formatu binarnego?)

W przypadku małej gry osobistej może się to nie zdarzyć, ale jednym z poważnych problemów związanych z danymi gry jest edycja / wersjonowanie dla wielu użytkowników. Używamy wielu małych plików tekstowych, które są upychane do niewielkiej liczby binarnych obiektów blob w procesie kompilacji. Ułatwia to życie projektantom, ponieważ mają dużą swobodę przepływu pracy. CCP jako przykład wykorzystuje centralną bazę danych edycji, z którą łączą się wszyscy projektanci. To sprawia, że ​​krok kompilacji nie jest potrzebny (lub przynajmniej o wiele prostszy), ale oznacza to, że musisz samodzielnie wdrożyć wszystkie funkcje wersjonowania i przepływu pracy, więc z pewnością będą one prostsze niż inne dostępne narzędzia. W obu przypadkach możesz poradzić sobie z wydajnością, więc prawdziwe pytanie brzmi: czego chcesz od przepływu pracy projektanta i jak się tam dostać?

JSON jest bardzo lekki i łatwy do zrozumienia. Myślę, że lepiej nadaje się do gry. cJSON jest naprawdę fajny. włącza się również do twojego źródła w taki sam sposób, jak SQLlite.

Pliki XML są trudniejsze do edycji dla użytkowników niż myślisz. jeśli pójdziesz tą drogą, możesz chcieć stworzyć edytor dla ludzi, który pomoże im uniknąć typowych pułapek.

Jestem spóźniony na przyjęcie tutaj, ale spędziłem DUŻO czasu na badaniu tego.

Po pierwsze, dlaczego nie używam następujących elementów:

XML: nadmiernie szczegółowy. Mnóstwo redundancji. Powtarzanie nazw pól? OBRZYDLIWY

JSON: Myślę, że JSON jest świetny dla układu interfejsu użytkownika, ale dla bazy danych, do diabła nie. Będzie miał takie same problemy jak XML, redundancja i głębokie zagnieżdżanie. OBRZYDLIWY.

SQL : Jest to świetna opcja, jeśli poradzisz sobie z problemami z konfiguracją. Stworzyłem gry mobilne, w których przechowujemy dane gry online w bazie danych SQL. Format tabeli jest niezły. Problem polegał na tym, że musieliśmy pobrać bazę danych z trybu online i ustawienie tego może być kłopotliwe. Ale SQL jest przyzwoitym rozwiązaniem. Unity nie obsługuje tego natywnie, a wtyczki, które wypróbowałem, miały poważne problemy (szczególnie, gdy próbowałem zmusić go do kontroli wersji).

Wreszcie, oto rozwiązanie, z którego zdecydowałem się skorzystać (i uwielbiam je).

CSV : prosty. Pozwala mi korzystać z formatu tabeli i mam jeden łatwy punkt odniesienia, gdy muszę go zaktualizować. Mogę mieć tabelę dla wszystkich moich broni, kolumny dla wszystkich atrybutów i wiersze dla każdego rodzaju broni.

Możesz używać Microsoft Excel, ale wyrzuca te głupie ostrzeżenia za każdym razem, gdy musisz zapisać. Możesz użyć makr, aby go zastąpić, ale mówię, że oszczędzaj sobie problemów i zdobądź LibreOffice . Jest darmowy, obsługuje edycję CSV, a po otwarciu pliku ładuje szerokość kolumny odpowiadającą nazwie (Excel tego nie robi i doprowadza mnie do szału).

Następnie musisz tylko przeanalizować pliki CSV w swojej grze. Używam Unity, więc wszystko, co musiałem zrobić, to użyć tego sprytnego analizatora składni C # CSV, który znalazłem:

Przykład parsera CSV

Konwertujesz pliki CSV na obiekty danych w grze i możesz zacząć. Dzięki Unity możesz zamienić je w ScriptableObjects . Więc mój przepływ pracy to: Zaktualizuj CSV -> Analizuj CSV w Skryptowalne Obiekty -> Używaj danych z ScriptableObjects w mojej grze

Odpowiedź zależy od tego, jakiego języka używasz w grze.

Jeśli używasz C ++, zalecamy skorzystanie z jednej z istniejących bibliotek XML (takich jak TinyXml lub eXpat ).

Z drugiej strony, jeśli korzystasz z PHP, możesz bardzo łatwo użyć serwera bazy danych, takiego jak MySQL lub SQLite. (Pamiętaj, że jeśli wybierzesz tę trasę, będziesz potrzebować więcej zasobów, ponieważ serwer bazy danych będzie działał jako osobny proces, a większe aplikacje baz danych, takie jak MySQL, mogą zużywać dużo pamięci RAM podczas działania.)

JSON nabiera tempa i jest z pewnością najlepszym wyborem, jeśli twoja aplikacja jest napisana w więcej niż jednym języku.

Krótko mówiąc, zależy to od tego, co jest łatwe w użyciu w twoim języku.

Jeśli chcesz pozostać w dziedzinie XML rzeczy, możesz użyć Binarnego XML, aby zwiększyć wydajność ładowania.

Na przykład Fast Infoset jest implementacją binarnego pliku XML

Można myśleć o Fast Infoset jako gzip dla XML, chociaż FI ma na celu optymalizację zarówno rozmiaru dokumentu, jak i wydajności przetwarzania, podczas gdy gzip optymalizuje tylko rozmiar. Podczas gdy oryginalne formatowanie jest tracone, żadne informacje nie są tracone podczas konwersji z XML na FI iz powrotem na XML.

Od lat projektuję bazy danych i bawiłem się wieloma pomysłami na gry. Moim ulubionym w tej chwili jest jakiś tekstowy, czytelny dla człowieka format konfiguracji, ale potem parsowanie tych „wolnych skryptów” w coś łatwiejszego do przejścia. Podobnie jak JAVA i .NET są kompilowane do kodu bajtowego w czasie wykonywania.

Ten sam pomysł idzie tutaj. Mam wersję „źródłową” komponentów, a następnie przechodzi przez nie prekompilator / parser. Jeśli zajmują zbyt dużo pamięci, możesz umieścić je w szybkiej bazie danych SQL lub zapisać jako pliki binarne. Ale chodzi mi o to, aby użyć pamięci lub bazy danych SQL jako obszaru roboczego / pamięci podręcznej, aby nie musieć analizować skryptów w kółko. Możesz stworzyć kompilator, przenieść przeanalizowane pliki do „source-lib” i w ten sposób pozwolić prekompilatorowi na wykonanie kontroli wersji (zachowując poprzednie pliki w celu przywrócenia).

Jeśli chodzi o „nieograniczoną przestrzeń na dysku twardym”, zarejestruj się w Dropbox lub Amazon S3 i zsynchronizuj się z nimi.

Więc plan dla mnie jest obecnie:

1. Config / scripts / xml (jakiś format czytelny dla człowieka) jako pliki tekstowe (podobnie jak kod źródłowy)
2. Analizator składni / sprawdzania poprawności, który uruchamia nowe skrypty i sprawdza, czy przestrzegają reguł
3. Kompilator tworzący wiersze binarne lub SQL z oryginalnych plików, dzięki czemu można je szybko odzyskać + uruchomić.

Jeśli chodzi o stabilność, obecnie buduję bazę danych, aby była „hostowana w kolokacji” i automatycznie synchronizowała również wiele lokalizacji, tak aby w przypadku awarii sieci / sprzętu w jednej lokalizacji inne witryny mogły obsługiwać ten sam ruch / gamestates.

Jeśli użyjesz couchdb , zasadniczo będziesz zapisywał wszystko jako strukturę JSON. Couchdb zadba o bezbolesną replikację danych (wielu) użytkowników.

Możesz znaleźć procedurę w Unity Wiki z PHP, MySQL i C # / JavaScript, i działa ona dobrze do swoich celów.

Składa się z trzech kroków

1. Utwórz pustą bazę danych MySQL i tabelę.
2. Utwórz skrypt po stronie serwera PHP (połączy się on z tabelą MySQL, odbierze dane ze skryptu Unity (krok 3) i przeszuka bazę danych (podane przykłady to wstawianie danych lub wybieranie))
3. Utwórz skrypt kontrolera Unity (połączy się ze skryptem PHP utworzonym w kroku 2)