Варианты как сохранять стату игрока
| |
dzrone3488 | Дата: Воскресенье, 23 Апреля 2017, 23:09 | Сообщение # 1 |
участник
Сейчас нет на сайте
| И так. Продолжаю работу над своим новым проектом, столкнулся со следующей проблемой: у игрока есть опыт, деньги, ачивки, пороль от акка, и всё это надо сохранить, так чтобы некто не смог изменить их через Cheat Enginie и.т.д. Не хочу, чтобы в топе сидели люди с Xp 9999999. Знаю, что самый лучший вариант это база данных, но работать с ней для меня - АД. Да и PHP у меня хромает (Я его не знаю ). Ну а кроме есть PlayerPrefs, обычный System.IO, но это мне как вы уже поняли не подойдёт. Вот я и пришёл к старцам за советом!!! Есть безопасный вариант сохранения? Может что-то типо базы данных но полегче?
Ну а теперь еще пару вопросов, вряд-ли кто ответит на них но мало-ли...
1) У Steam есть своё облако? Как с ним работать? 2) В VK как происходит сохранение в реестр? А то вроде сохраняется а реестр пустой
Заранее спасибо за помощь!
Я делаю игры, а вы в них играете! :) Моя группа по созданию игр - www.vk.com/dzrone
|
|
| |
Эргалон | Дата: Понедельник, 24 Апреля 2017, 00:35 | Сообщение # 2 |
Вездесущий
Сейчас нет на сайте
| Ты ведь понимаешь, что, чтобы был список топа и его все видели, тут никак не обойтись без бд, к которой будет доступ всем игрокам? Не хочешь видеть читеров в топе - бань. По сохранению данных, просто в условно текстовый файл записывай все данные, напиши энкодер/декордер этого файла(если к примеру будет использоваться хоть какая-то шифровка, что советую) вот в прочем и всё. Накрутка чего либо в игре делается не за счет редактирования файла сохранений(хотя и это тоже, но очень редко, т.к все же эти данные шифруют), а напрямую через игровой клиент, при помощи подмены значений, также отправляют и левые запросы на сторону сервера, если к примеру идет оправка, что ты там собрал 100 очков и если эти данные отсылаются в открытом ввиде их очень просто подменить, как и накрыть вообще всю бд.
Кубариум Rise of the dark lords
Сообщение отредактировал Эргалон - Понедельник, 24 Апреля 2017, 00:38 |
|
| |
URGINSAN | Дата: Понедельник, 24 Апреля 2017, 10:14 | Сообщение # 3 |
почти ветеран
Сейчас нет на сайте
| dzrone3488, как вариант кодировать данные через md5, потом полученное значение опять через md5, и так несколько раз)) Не один хакер-читер не раскодирует)
Я на драйве
|
|
| |
Эргалон | Дата: Понедельник, 24 Апреля 2017, 18:06 | Сообщение # 4 |
Вездесущий
Сейчас нет на сайте
| URGINSAN, Цитата как вариант кодировать данные через md5, потом полученное значение опять через md5, и так несколько раз)) Не один хакер-читер не раскодирует)
Абсолютной защиты нет. Этот вариант огородит от дилетантов, нормальный взломщик обойдет эту систему на раз.
Кубариум Rise of the dark lords
Сообщение отредактировал Эргалон - Понедельник, 24 Апреля 2017, 18:07 |
|
| |
Abel399 | Дата: Понедельник, 24 Апреля 2017, 19:48 | Сообщение # 5 |
Surpass your limits. Right now.
Сейчас нет на сайте
| Эргалон,
Цитата Эргалон ( ) нормальный взломщик
#define "нормальный взломщик"?) Тот, кто просто умеет перехватить пакеты и применить к ним ряд эвристических алгоритмов? х) [а порой даже и элементарных обратных функций]
По сабжу: jmp 465554555245 -> В данной задаче будет достаточно даже элементарного хранения данных в бинарном файле и использования защиты от дурака
Любая структура, хранящая данные, подчиненные определенным правилам, и имеющая возможности их добавления/удаления/обновления, является базой данных. Другой момент - как вы ее представите. # Варианты: 1) Один/ряд текстовых/бинарных файлов, где хранятся данные, обработанные одним (а чаще несколькими) из алгоритмов шифрования; 2) JSON, XML, YAML и подобные в чистом или так же "скомпилированном" виде (с оговорками, но легче, чем СУБД); 3) Реляционная база данных и СУБД (MySQL, SQLite, PostgreSQL, Firebird и т.д.); * СУБД тоже делятся на виды: какие-то являются клиент-серверными (PostgreSQL, MySQL), другие - встраиваемыми (SQLite, Firebird) и т.д. 4) Сохранение данных в памяти сервера с dump'ом через определенный промежуток времени; 5) Можно упороться и завести структуру данных аля ассоциативный массив (на хеш-таблицах или деревьях -> зависит от подхода), хранить все данные в ней и время от времени проводить ее сериализацию с последующим сохранением (ИМХО - в чистом виде не имеет права на жизнь).
Естественно не стоит выбирать только один способ, их нужно комбинировать. В продакшене как правило используется концепция/технология ORM + реляционная база данных, но никто не запрещает сделать тоже самое, используя тот же JSON -> It depends on needs.
Но все это решаемо и не представляет из себя никакой сложности. # Куда более важные проблемы: * Какая архитектура используется в приложении? * Какой уровень доступа предоставляется пользователю к его данным? * Как часто пользователь должен обращаться к серверу, чтобы запросить свои данные? * Должен ли он вообще обращаться к серверу за определенным видом данных?
# Несколько советов по хранению и передаче данных: - Никогда не хранить пароли и другую конфиденциальную информацию в чистом виде, всегда применять к ним хеширование (SHA2, SHA3) и сравнивать по хешу - При необходимости применять ряд алгоритмов шифрования/хеширования - Всегда использовать уникальную для каждого пользователя "соль" (вики) - Никогда не доверять пользователю, он врет -> 1. Хранить данные на сервере и производить их изменение там же, отсылать и получать данные с предварительным шифрованием, а еще лучше - вовсе не передавать данные напрямую, а использовать отправку событий (аля он нашел клад +3к опыта) с их предварительной проверкой на валидность (использование контрольных сумм, например) 2. При хранении же на стороне клиента применять вычисление контрольных сумм, проверку хешей и проводить четкий контроль при изменении данных - При необходимости передачи данных через HTTP использовать HTTPS - Защита от "дурака" тоже защита. Даже элементарное дублирование всех переменных с определенным ключом смещения и последующей их проверкой-сравнением дает результат - При особой надобности пиши свою функцию шифрования на основе уже существующих. Очень примитивный пример:
Код # Python3 def to_ascii(h): strs = "" for i in range(len(h)//2): strs += chr(int(h[(i*2):(i*2)+2], 16)) return strs
def to_hex(s): strs = "" for i in range(len(s)): strs += "%x"%(ord(s[i])) return strs
def crypt(message): for i, v in enumerate(message): message = message[:i] + chr(ord(v)-12) + message[i+1:] return to_hex(message)
def de_crypt(message): message = to_ascii(message) for i, v in enumerate(message): message = message[:i] + chr(ord(v)+12) + message[i+1:] return message
crypted = crypt("Crypted_String") print(de_crypt(crypted))
P.S> Это всего лишь неточная теоретическая выдержка и ряд вполне очевидных, но полезных советов. Пользоваться ими или нет - дело лично каждого.
Ninja Slayer - 2D Physics Puzzle [cancelled]
Сообщение отредактировал Abel399 - Понедельник, 24 Апреля 2017, 19:53 |
|
| |
|