Twoje pytanie jest bardzo szerokie ze względu na dużą liczbę gatunków, ale oto perspektywa profesjonalnego programisty.
Podano listę kryteriów, których chcesz użyć, aby określić, którego mechanizmu utrwalania danych używasz. Były to:
- Wielkość projektu.
- Platforma docelowa dla gry.
- Złożoność struktury danych.
- Przenośność danych w wielu projektach.
- Jak często należy uzyskiwać dostęp do danych
- Wiele typów danych dla tej samej aplikacji
- Każdy inny punkt, który uważasz za interesujący przy podejmowaniu decyzji, czego użyć.
Najpierw musimy ustalić, które opcje są dla nas dostępne. Ponieważ nie określiłeś języka ani technologii, trudno powiedzieć dokładnie, ale prawdopodobnie próbujesz wybrać między XML a relacyjną pamięcią bazy danych.
Ważnym rozróżnieniem jest to, że XML nie jest tak naprawdę mechanizmem przechowywania , a techniką serializacji. To sposób na reprezentowanie struktur w pamięci dla twojej gry. Biorąc to pod uwagę, naprawdę mówisz o płaskim pliku vs. relacyjnym przechowywaniu bazy danych. Nie są to jedyne opcje, ale są najczęstsze, więc zamierzam ich użyć.
W przypadku plików płaskich:
- XML
- JSON
- YAML
- XAML
- Zwykły tekst
W przypadku baz danych:
- SQL Server
- MySQL
- DB2
- Wyrocznia
- Wiele więcej
EDYCJA: Pytałeś o inne typy mechanizmów oprócz plików i relacyjnych baz danych. Jedynym innym godnym uwagi typem bazy danych, z którego regularnie korzystałem, są bazy danych w stylu „Berkeley”, które są zasadniczo oparte na klucz-wartość. Zwykle używają drzewek B do uporządkowania danych, dzięki czemu wyszukiwanie jest szybkie. Doskonale nadają się do wyszukiwania konfiguracji / ustawień, w którym dokładnie wiesz, czego chcesz (np. Podaj mi wszystkie dane telemetryczne dla „Poziomu 1”).
Teraz, gdy mamy już wszystkie podstawy, pomówmy o twoich kryteriach.
Wielkość projektu.
Niektórzy mogą się nie zgodzić, ale rozmiar projektu niekoniecznie będzie miał duży wpływ na mechanizm utrwalania danych. Będziesz chciał zbudować bibliotekę funkcji wielokrotnego użytku, które przechowują / ładują dane z dowolnego mechanizmu. Sugerowałbym nawet zaimplementowanie warstwy abstrakcji (sprawdź wzorzec adaptera ), aby w razie potrzeby można było łatwo zmienić mechanizm trwałości.
Powiedziawszy to, w przypadku małych projektów używanie XML w systemie plików może potencjalnie działać dobrze, ale będziesz chciał rozwiązać niektóre z twoich problemów związanych z bezpieczeństwem (np. Szyfrowanie), aby gracze nie mogli zmieniać danych do woli.
Platforma docelowa dla gry.
Platforma też nie będzie wielkim problemem. Powinieneś bardziej martwić się platformą programistyczną niż platformą docelową. Powodem tego jest fakt, że niektóre języki radzą sobie z niektórymi typami znaczników lub bazami danych lepiej niż inne po wyjęciu z pudełka. Nie oznacza to, że nie można użyć żadnego z powyższych w prawie żadnym języku, ale czasami najlepiej jest użyć obsługiwanych narzędzi, które są dostępne. Każda platforma będzie obsługiwać płaskie pliki i analizować XML, ale na platformach mobilnych możesz rozważyć binarną serializację, jeśli to możliwe, lub przynajmniej zoptymalizować XML pod kątem przechowywania.
Złożoność struktury danych.
To jest dość trudne. Relacyjne bazy danych doskonale nadają się do ... przechowywania obiektów i ich relacji. Masz lepszą możliwość egzekwowania struktury przy użyciu relacyjnego repozytorium pamięci niż w przypadku plików w systemie plików. Weź pod uwagę rodzaje relacji między swoimi bytami, a także częstotliwość ich zmieniania lub znajdowania powiązanych podmiotów. W przypadku bardzo skomplikowanych struktur sugerowałbym wybranie trasy do bazy danych.
Przenośność danych w wielu projektach.
Jeśli chodzi o przenośność, należy wziąć pod uwagę fakt, że bazy danych mają naturalnie większą wagę niż pliki. Narzut związany z instalacją i konfiguracją, różne bazy danych będą dostępne dla różnych platform itp. SQLite jest całkiem dobrym rozwiązaniem. Jednak jeśli chodzi o przenośność, prawdopodobnie będziesz miał łatwiejszy czas dzięki rozwiązaniom opartym na plikach, takim jak XML.
EDYCJA: Istnieją pewne inne obawy, które wspomniałeś o przenośności w jednym z twoich komentarzy. Ostatecznie nie chcesz, aby Twoje dane były zbyt ściśle powiązane z jakimkolwiek produktem lub typem pliku. Ostatecznie najlepiej jest przechowywać dane podstawowe (poziomy, wrogów itp.) W jakimś abstrakcyjnym formacie (pliki rozdzielane tabulatorami, XML itp.), Które można łatwo analizować i przechowywać w bazie danych / systemie plików podczas kompilacji lub ładowania czas. Oznacza to, że możesz wymienić mechanizm przechowywania według kaprysu i po prostu przepisać kawałek parsowania.
Jak często należy uzyskiwać dostęp do danych
Dużo dostępu do danych oznacza wiele operacji we / wy, chyba że masz jakiś mechanizm buforowania. Bazy danych przechowują struktury w pamięci i doskonale nadają się do manipulacji i wyszukiwania danych. Jeśli naprawdę stale utrwalasz dane, możesz chcieć trzymać się bazy danych.
Wiele typów danych dla tej samej aplikacji
Wolumen jest z pewnością kwestią do rozważenia, ale jeśli nie mówimy o utrwalaniu tysięcy lub milionów obiektów, system plików nadal będzie akceptowalny jako rozwiązanie.
Rodzaj gry
Rodzaj budowanej gry może mieć ogromny wpływ na wybraną platformę. Tak, w przypadku większości gier jednoosobowych tylko dla klienta, wszystko będzie dobrze, korzystając ze skompresowanego lub zaszyfrowanego rozwiązania opartego na systemie plików. Jeśli mówisz o grach z komponentem online, byłoby to szalone. Wybierz trasę do bazy danych i oszczędzaj sobie bólu głowy. Pozwól serwerowi zarządzać wszystkimi Twoimi danymi za pomocą klastra zaplecza.
Mam nadzieję, że niektóre z tych opinii pomogą. Nie jest to w pełni wyczerpujące, a decyzja należy do ciebie, ale mój komentarz powinien dać ci kilka rzeczy do przemyślenia.
EDYCJA: Są chwile, kiedy podejście hybrydowe ma sens. Załóżmy na przykład, że pracujesz nad MMORPG. Po stronie klienta możesz przechowywać buforowane dane o innych graczach w nierelacyjnej bazie danych (jak wspomniano powyżej). Po stronie serwera przechowujesz wszystkie dane gry w relacyjnej bazie danych, aby je zachować. A potem znowu po stronie klienta prawdopodobnie przechowujesz dane dziennika, dane konfiguracyjne itp. W plikach XML / flat dla łatwiejszego dostępu.
W innym plakacie wspomniano również, że czasami miło jest, nawet jeśli przechowujesz dane do produkcji w bazie danych, aby zamiast tego użyć płaskich plików do programowania ... łatwiej jest usunąć inny produkt z miksu .