Gaming Databases Theory

Question

Ich möchte etwas Hilfe mit Data Management Theorie für Android-Spiele. Ich entwickle ein Rollenspiel und ich möchte, dass der Charakter mit verschiedenen Outfits angepasst werden kann: Hüte, Power Armor Weapons, etc. Der Spieler kann diese in einem Shop kaufen und dann wählen, ob er sie tragen oder das Outfit wechseln möchte Artikel in einer "Garderobe", um eine andere Zeit zu tragen.

Bisher wurden die meisten meiner Daten über SharedPreferences gespeichert. Ich weiß jedoch, dass dies nicht für 100 verschiedene Arten von Gegenständen ist, die der Spieler kaufen und dann speichern kann, um sie zu einem anderen Anlass zu tragen.

Durch Forschung, ich fange an zu glauben, dass SQLite in Android Studio am besten wäre. Würde jemand damit einverstanden sein oder einen besseren Vorschlag haben?

Ich verstehe, dass SQLite mir erlauben würde, die Daten mit einem "nicht gekauften" Status vorgeladen zu haben. Bei "gekauft" würde sich dieser Status ändern und der Spieler könnte die Kleidung "tragen" oder "nicht tragen".

Wenn SQLite am besten ist, wie gehe ich am besten vor? Nimmt SQLite außerdem viel Zeit zum Laden und verlangsamt daher das Öffnen einer Aktivität? Könnten Sie SQLite mit SharedPreferences kombinieren, um sich an das zuletzt ausgewählte Outfit zu erinnern?

Schließlich ist SQLite, was andere Apps verwenden, um Daten zu speichern (besonders wenn sie über Android Studio erstellt werden)? Wie speichern Spiele wie "Clash of Clans" oder "Tapped Out" solche Daten wie eigene Gegenstände oder Orte auf einem Gitter?

Vielen Dank für die teilweise Unterstützung oder Theorie.

Answer 1

TL; DR Ja, SQLite ist in Ordnung.

Lassen Sie mich diese Frage von Clean Code Perspektive beantworten.

Die Antwort unten könnte zu kompliziert für die Anfänger sein, aber ich hoffe, dass es auf lange Sicht hilfreich sein wird.

Ich denke, Ihre eigentliche Frage ist - wie speichere ich die Sachen, die ich später brauche? In den meisten Fällen spielt es keine Rolle, wie Sie die Daten speichern, solange Sie sie später zuverlässig wieder lesen können. Anstatt sich über "sollte ich X benutzen?" Gedanken zu machen, würde ich stattdessen mit der Definition der Schnittstelle der Klasse beginnen, die Ihr Problem lösen wird.

Zum Beispiel nennen wir es PlayerItemsRepository und es ist verantwortlich für das Speichern Ihrer Sachen und das Lesen zurück. Wie? Ich weiß es noch nicht, wir können es später herausfinden.

public interface PlayerItemsRepository { 

    void saveItems(List<Item> items); 

    List<Item> readItems(); 

} 

OK, jetzt können wir SQLite integrieren? Lassen Sie uns damit ein wenig warten - es ist ein bisschen wie ein Standardcode, um mit SQLite zu arbeiten, also wie würden wir eine einfache Implementierung dieser Schnittstelle erstellen, die nur die Liste serialisieren und in Datei speichern würde (vorausgesetzt, Ihre Item ist Serializable) . Oder wenn wir selbst zu faul sind, wie wäre es, wenn wir einfach unsere List<Item> in JSON konvertieren und sie in SharedPreferences speichern (mit so etwas wie einer Gson-Bibliothek, die dumm ist - einfach zu benutzen)?

Jetzt, wenn Sie nur 100 Elemente (die eine eher kleine Menge) speichern, bin ich ziemlich sicher, dass all diese "einfachen" Lösungen einfach gut funktionieren und Sie können die ganze Geschichte einfach vergessen.

Wenn Sie starten in die Notwendigkeit zu laufen irgendeine Art von relationalen Modell zu haben, oder die Leistung von Serialisierung ist nicht akzeptabel für Sie, oder Sie brauchen eine schnellere und kompliziertere Such Mechanik - dann Sie Schalt könnte prüfen zu SQlite. Es ist ziemlich üblich für Android-Anwendungen, obwohl (wie ich bereits erwähnt habe) API ist etwas umständlich und erfordert, dass Sie einige Boilerplate schreiben - was am Ende erfordert, dass Sie mehr Zeit darauf verbringen, und es könnte die Zeit nicht wert sein ein kleiner Datensatz.