Среда, 13 Ноября 2024, 11:12

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
Варианты как сохранять стату игрока
dzrone3488Дата: Воскресенье, 23 Апреля 2017, 23:09 | Сообщение # 1
участник
Сейчас нет на сайте
И так. Продолжаю работу над своим новым проектом, столкнулся со следующей проблемой: у игрока есть опыт, деньги, ачивки, пороль от акка, и всё это надо сохранить, так чтобы некто не смог изменить их через Cheat Enginie и.т.д. Не хочу, чтобы в топе сидели люди с Xp 9999999. Знаю, что самый лучший вариант это база данных, но работать с ней для меня - АД. Да и PHP у меня хромает (Я его не знаю :) ). Ну а кроме есть PlayerPrefs, обычный System.IO, но это мне как вы уже поняли не подойдёт. Вот я и пришёл к старцам за советом!!! Есть безопасный вариант сохранения? Может что-то типо базы данных но полегче?

Ну а теперь еще пару вопросов, вряд-ли кто ответит на них но мало-ли...

1) У Steam есть своё облако? Как с ним работать?
2) В VK как происходит сохранение в реестр? А то вроде сохраняется а реестр пустой

Заранее спасибо за помощь! lovegcup


Я делаю игры, а вы в них играете! :)
Моя группа по созданию игр - 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
  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг