Теория игр для игр

Question

Мне нужна помощь в теории управления данными для Android-игр. Я разрабатываю ролевую игру, и я хотел бы, чтобы персонаж настраивался с помощью разных нарядов: шляп, оружия с силовой броней и т. Д. Игрок может купить их из магазина, а затем выбрать, носить или менять наряд, но сохранить вещь в «гардеробе», чтобы носить другое время.

До сих пор большинство моих данных были сохранены с помощью SharedPreferences. Однако я знаю, что это неустойчиво для 100 различных типов предметов, которые игрок может купить, а затем сохранить для ношения в другом случае.

Благодаря исследованиям, я начинаю считать, что SQLite будет лучше всего в Android Studio. Кто-нибудь согласится с этим или предложит лучшее предложение?

Я понимаю, что SQLite позволит мне предварительно загружать данные с статусом «не купленный». Когда «купил», этот статус изменится, и игрок сможет «носить» или «не носить» одежду.

Если SQLite лучше, как мне лучше всего это делать? Кроме того, SQLite занимает много времени для загрузки и, следовательно, замедляет открытие активности? Не могли бы вы объединить SQLite с SharedPreferences, чтобы запомнить последнюю выбранную экипировку?

И, наконец, SQLite, что другие приложения используют для хранения данных (особенно, если они созданы через Android Studio)? Как такие игры, как Clash of Clans или Tapped Out, сохраняют такие данные как принадлежащие им предметы или местоположение на сетке?

Благодарим вас за частичную поддержку или теорию.

Answer 1

TL; DR Да, SQLite в порядке.

Позвольте мне ответить на этот вопрос с точки зрения чистого кода.

Ответ ниже может быть слишком сложным для начинающих, но я надеюсь, что это будет полезно в долгосрочной перспективе.

Я думаю, что ваш фактический вопрос - как мне сохранить материал, который мне понадобится позже? В большинстве случаев на самом деле не имеет значения, как вы будете хранить данные до тех пор, пока вы сможете надежно прочитать их позже. Итак, вместо того, чтобы беспокоиться о том, «должен ли я использовать X?», Вместо этого я бы начал с определения интерфейса класса, который решит вашу проблему.

Например, назовем его PlayerItemsRepository и он будет нести ответственность за сохранение ваших вещей и их чтение. Как? Я еще не знаю, мы можем понять это позже.

public interface PlayerItemsRepository { 

    void saveItems(List<Item> items); 

    List<Item> readItems(); 

} 

ОК, теперь мы можем интегрировать SQLite? Давайте подождем с этим немного - это немного код шаблона для работы с SQLite, поэтому как насчет создания некоторой простой реализации этого интерфейса, которая просто сериализует список и сохраняет его в файл (если ваш Item равен Serializable) , Или, если мы слишком ленивы даже для этого, как насчет того, что мы просто преобразуем наш List<Item> в JSON и сохраним его до SharedPreferences (с чем-то вроде библиотеки Gson, которая глупо-проста в использовании)?

Теперь, если вы сохраняете только 100 предметов (что довольно небольшое количество), я уверен, что все эти «легкие» решения будут работать нормально, и вы сможете просто забыть обо всей истории.

Если вы начнете работать в необходимость иметь какую-реляционную модель, или производительность сериализации не является приемлемым для вас, или вам нужен более быстрых и более сложных поисковых механики - того вы можете рассмотреть вопрос о переходе к SQlite. Это довольно распространено для приложений для Android, хотя (как я уже упоминал ранее) API несколько громоздкий и требует, чтобы вы написали довольно какой-нибудь шаблон, который в конечном итоге требует от вас потратить больше времени на это, и это может быть не стоит времени для небольшой набор данных.