Должен ли я использовать текстовые файлы для сохранения данных?


22

У меня вопрос, стоит ли мне использовать текстовые файлы для сохранения игровых данных. У меня есть некоторые основные проблемы по поводу этого:

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

  2. Вероятно, это не самый эффективный способ хранения моих данных (их будет много)

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

Если я не должен использовать текстовые файлы, что я должен использовать? Мне нужно что-то совместимое с C ++.


2
Zip-файлы (с паролем) - есть много доступных библиотек, которые позволят вам сделать это, и это должно сэкономить место на диске
SeanC

2
Применение простого шифра, такого как en.wikipedia.org/wiki/ROT13, должно быть достаточно, чтобы не дать обычному пользователю редактировать файлы. Все остальные, вероятно, знают, что они делают в любом случае.
Exilyth

1
По-своему, но мне нравится, что мои игры легко модифицируются.
mmyers

Ответы:


28

На данный момент, так как вы только начинаете, текстовые файлы, вероятно, в порядке. В вашем вопросе есть пара вопросов, на которые я отвечу.

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

  2. Производительность - это еще кое-что, что мы часто не планируем должным образом. Вы не должны действительно оптимизировать, пока не измерите проблему производительности. Я думаю, что вы , вероятно, количество данных, которое не что большие и что текстовые файлы будут просто отлично.

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

class DataWriter {
  virtual void save(GameState state) = 0;

  virtual ~DataWriter() { }
};

class TextFileDataWriter : public DataWriter {
  virtual void save(GameState state) {
    //write to text file
  }
};

class DatabaseDataWriter : public DataWriter {
  virtual void save(GameState state) {
    //write to database
  }
};

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


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

6
@Althezel Дело в том, что независимо от того, как вы сохраняете свои данные, кто-то, кто решил их изменить, сможет это сделать. В этом смысле, как правило, тратить ваше драгоценное время на разработку, чтобы попытаться установить защиту :)
pwny

@Althezel Что касается баз данных, думайте о них как о неком механизме, которому вы передаете запросы на чтение или запись данных. Этот механизм отвечает за сохранение / чтение его эффективным способом, обычно в реляционной форме в таблицах. В вашем случае я бы посмотрел на SQLite ( sqlite.org ). В основном вы будете использовать библиотеку C ++ для подключения к локальной базе данных SQLite (SQLite использует локальные файлы) и передавать вызовы этой библиотеки в синтаксисе SQL для доступа к вашим данным.
pwny

2
Это печальный мир, когда разработчики хотят иметь возможность блокировать пользователей от информации, которую они хранят на своих компьютерах.
ClassicThunder,

2
Использовать текстовые файлы просто непрофессионально, потому что очень немногие игры хранят вещи как «save-data.txt» - но если вы когда-нибудь тратили время на просмотр большинства сохраненных игровых файлов, вы обнаружите, что они часто являются не более чем текстовыми файлами. иногда к ним добавляются двоичные данные. Например, в каждой игре серии Civilization и Total War используются файлы .txt для широкого спектра игровых данных. Наиболее распространенным «обновлением» для этого является система баз данных, которая в конечном итоге хранит данные в виде плоского файла, который, за исключением некоторых двоичных двоичных объектов, представляет собой просто текстовый файл.
BrianH

3

Слово «Игровые данные» может означать много вещей, например

  • GameState
  • Конфигурационные файлы
  • Карты, текстуры, звуки, скрипты, данные анимации, ...
  • локализация
  • Данные макета GUI
  • больше я не думал о

Для каждой категории вы можете использовать другой подход.

Например, вы можете использовать SQLite для локализации, двоичный файл для карт, текстуры, звуки и так далее.

Для настройки конфигурации вы должны использовать легко изменить XML-файлы.

Как всегда, правильный ответ - «это зависит».

Существует много парсеров xml с привязкой c ++, а также существует привязка c ++ для SQLite.


Это может быть религиозным делом, но я бы предпочел использовать формат файлов INI для конфигов вместо XML. Последний чувствует себя излишним для этого сценария. И в читающих библиотеках есть INI ридер.
Артур Цайка,

0

Вы можете сохранить свои данные в виде двоичного двоичного объекта и передать данные обратно, когда вы получите доступ к этому файлу. Это решит обе ваши проблемы. Просто убедитесь, что код сериализации в точности совпадает с десериализацией.

Потоковая передача в двоичном двоичном объекте является относительно быстрой, а также не позволяет пользователю видеть данные и изменять их.

Вы можете достичь всего этого, используя стандартные потоки библиотеки.


2
Хотя двоичный двоичный объект является быстрым и простым (как для разработки, так и для загрузки / запуска), самая большая проблема, с которой я столкнулся в двоичном двоичном объекте, заключается в том, как только вы что- то измените в организации структуры данных (настолько, что добавите один floatэлемент к одному объект), старые сохранения становятся полностью недействительными. С этим трудно разобраться во время разработки, но если вы готовы, то во что бы то ни стало.
Бобобо
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.