який найбільш використовуваний метод чи алгоритм для збереження ігрового стану (профілів), текстові файли баз даних, як відбувається шифрування та пов'язані речі.
Я бачив, як Цезар IV використовував mySQL.
будь-які пропозиції.
який найбільш використовуваний метод чи алгоритм для збереження ігрового стану (профілів), текстові файли баз даних, як відбувається шифрування та пов'язані речі.
Я бачив, як Цезар IV використовував mySQL.
будь-які пропозиції.
Відповіді:
Я впевнений, що найчастіше це робиться у фірмовому (двійковому) форматі, просто записуючи кожну змінну з будь-якої структури гри гри, яку ви використовуєте у файл, або читання цього файлу в екземпляр структури. Наприклад, в C ++ ви можете обробити об'єкт, як масив байтів, і просто переписати його () у файл або завантажити Fread () з файлу та повернути його в його об'єктну форму.
Якщо ви використовуєте Java або іншу мову, ви можете вибрати серіалізацію, щоб зробити завдання справді легким. Пояснення Java знаходиться внизу цієї відповіді; інші мови (вищий рівень, ніж C ++), безумовно, також мають власні бібліотеки серіалізації або вбудовані функції, які ви бажаєте використовувати. Незалежно від того, наскільки неефективним може бути рутифікація серіалізації, простір на жорсткому диску в даний час коштує дешево, особливо коли ігровий стан взагалі не повинен бути дуже великим, і це заважає писати та підтримувати власні процедури серіалізації.
Вам абсолютно не слід використовувати MySQL (просто прочитайте перше речення цього огляду ). Якщо вам дійсно потрібна реляційна база даних з якихось причин, використовуйте SQLite ; це легка система баз даних і існує в одному файлі бази даних. Але для більшості ігор реляційні бази даних - це не шлях, і компанії, які намагаються їх використовувати, зазвичай використовують їх як таблицю пошуку ключових значень, а не як справжню реляційну базу даних.
Будь-яке зашифрування файлів локальних дисків є лише придушенням ; будь-який хакер просто обнюхає дані відразу після того, як програма розшифрує їх. Я особисто проти такої речі, ОСОБЛИВО з іграми для одного гравця. На мою думку, власникам гри (платять клієнти, майте на увазі), слід дозволити хакнути гру, якщо вони хочуть. У деяких випадках це може створити більше почуття спільності, і "модники" можуть бути розроблені для вашої гри, які приводять більше клієнтів до вас. Найновіший приклад, який спадає на думку, - нещодавно випущений портал в моді Minecraft . Він публікується на сайтах новин для геймерів по всьому Інтернету, і ви можете поставити під сумнів, що це збільшило продажі Minecraft.
Якщо з якоїсь причини ви насправді досить божевільні, щоб використовувати Java для розвитку ігор, як я, ось коротке пояснення серіалізації на Java:
Зберігайте всі ваші дані про стан ігор в одному класі, зробіть клас серіалізаційним шляхом впровадження
Serializable, використовуйтеtransientключове слово, якщо ви змішуєте спеціальні змінні змінні в клас (перехідні об'єкти не серіалізуються), і просто використовуйтеObjectOutputStreamдля запису у файл таObjectInputStreamдля читання з файлу . Це воно.
[field: NonSerialized]
Якщо ви пишете власний код, скажімо, на C ++, ви можете використовувати двійкові файли. Бінарні файли надають форму шифрування за допомогою обтурації. Але як це зафіксовано у всіх мережах, це дуже слабка форма безпеки.
АБО ви можете використовувати щось на зразок RapidXML, якщо хочете зрозуміти людину.
Якщо ви використовуєте якийсь фреймворк, перегляньте його функції підтримки файлів. HTH
Більшість ігор, які я бачив, просто використовують рукописний код для читання / запису з двійкових файлів. Часто формат на диску є точною репліку макета пам’яті об’єкта, тому завантаження просто:
Це швидко, але це завдання для обслуговування, орієнтованого на платформу та негнучкість.
Останнім часом я бачив, як пара ігор використовує SQLite. Людям, з якими я говорив, здається, це подобається.
Серіалізація згадується в деяких інших відповідях, і я згоден, що це розумне рішення. Один із способів цього не вдається, але це версія.
Скажімо, ви випускаєте свою гру і люди в неї грають і створюють кілька ігор для збереження. Потім в наступному патчі потрібно виправити помилку або додати деякі функції. Якщо ви використовуєте простий метод бінарної серіалізації та додаєте учасника до своїх класів, ваша серіалізація може бути не сумісна зі старими іграми збереження, коли клієнти встановлюють ваш патч.
Отже, яким би підходом ви не користуєтесь, обов’язково подумайте над цим питанням перед тим, як випустити гру вперше! Клієнти не будуть раді, якщо їм доведеться починати заново після накладення виправлення.
Один із способів уникнути цього - це кожен базовий тип даних реалізувати Save (version) та Load (version) методи, які досить розумні, щоб знати, які дані зберігати та завантажувати для кожної версії гри. Таким чином ви можете підтримати зворотну сумісність своїх ігор для збереження та вийти з ладу, якщо користувач намагається завантажити збережену гру з нової версії гри, ніж вона працює.
Якщо ви можете використовувати той самий формат, який ви використовуєте для зберігання своїх рівнів, це бонус.
Наприклад, така гра, як Peggle, може мати початковий макет дошки, кількість кульок, поточний рахунок (0 для початкової дошки) тощо. Потім збережена гра може використовувати саме той самий формат.
Якщо ви використовуєте той самий формат, то гра збереження та завантаження рівнів можуть ділитися кодом, полегшуючи вашу роботу!
Для гри з дійсно великими картами, гра збереження може включати файл карти за посиланням. Файли початкового рівня можуть зробити те саме, що навіть полегшує повернення на цю карту, якщо з якоїсь причини історія має характер повернутися до того самого місця, за винятком того, що деякі NPC загинули, а трупи лежать усі над.