Всем здравствуйте! У меня готов прототип игры и теперь стоит вопрос сохранения игрового прогресса. Всех игроков я хочу хранить в базе данных MySQL, там у меня хранятся таблицы с аккаунтами и самими персонажами. Вопрос в другом, также в игре есть около 50 различных уровней, а уровни еще разбиты на сложности(легкий, средний, сложный), как мне лучше сохранять такой прогресс в базе? Мне нужно каждый уровень заносить отдельной строчкой в таблице(например таблица Levels)?? Но тогда у меня будет около 50 строк на каждого игрока, а если игроков тысячи? Может можно как-то сохранять все уровни в одну строчку? (Да, можно и в одной строчке сделать 50 столбцов, но я не уверен, что это правильно...) Тот же вопрос касается и инвентаря персонажа, на каждого персонажа у меня по 40 ячеек слотов в сумке, как мне её сохранять, каждый слот отдельной строкой в таблице(Inventory) или можно как-то одним массивом хранить??? А может рядом с базой данных можно хранить какой-то файл который в себе несет всю информацию(типа сейв файла), а в бд просто в таблице делать ссылку на этот файл? Вообщем, прошу помощи как лучше сохранять такой объем информации используя базу данных, всем спасибо, всех с новым годом!!
Я в mySql не особо профи, но как понял, вы предлагает как раз там создать таблицу типа text или blob и туда сохранять сериализованный объект? А как определить, что лучше для меня text или blob? Спасибо за ответ!
CREATE TABLE `studentlogin`.`gamestate` (
`id` INT NOT NULL AUTO_INCREMENT,
`userid` INT NULL,
`gamedata` TEXT NOT NULL,
`created` DATETIME NOT NULL,
PRIMARY KEY (`id`),
INDEX `ix_user_id` (`userid` ASC),
INDEX `ix_created` (`created` DESC));
Воу, спасибо большое! Походу, это то что мне нужно. Я постоянно в своих играх сохраняю всё в XML, а потому умею с ним хорошо работать, буду пробовать идти по этому пути! Не думал, что xml можно с БД смешать.
Я так понимаю, вы разбираетесь в бд, а подскажите, если у меня xml файл вешает около 6-8 кб и кол-во строчек в нем около 120, это критичный вес или норм? Отправлять конечно же я это не очень часто буду в базу, по большей части по завершению уровня, но инвентарь могу и почаще(логично, что отдельно инвентарь и уровни я разобью на разные файлы).
AkaruZ, Это не критично, вполне нормально держать до 2 мегабайт, многие хранят картинки, и отстаивают свое право это делать.
Единственное на что стоит обратить внимание это на сохранение состояния из разных потоков.
То есть вам нужно сделать блокировку на уровне строки. Или в коде иметь только один экземпляр этого класса что бы только он мог писать и считывать изменения.
50 тысяч строк это вообще не проблема.
Если состояние каждого уровня хранить как байт, то это всего 50 кбайт.
Даже если хранить как строки, с учетом накладных расходов mysql, займет ну пару мегабайт.
На данном этапе можно вообще не париться.
Инвентарь - тоже, каждый предмет в отдельной строке с указанием владельца и места, и всех параметров предмета.
Базы данных были для того и созданы, что подобного уровня объемы это мелочи.
Я об этом уже тоже думал, но так как не имел опыта с такими объемами, потому решил изначально спросить у опытных людей дабы не пойти по ложному пути.
Вообще я больше переживаю не столько за размер БД сколько за скорость её работы.
Вот например если у меня 5000 игроков было, тогда это около 250к строк (по 50 строчек уровней на каждого игрока), насколько базе тяжело делать выборку по имени персонажа?
ну давайте посчитаем.
5000 игроков. На каждого, допустим, 10 килобайт, чтобы вообще с запасом. Получаем 50.000 килобайт, то есть 50 мегабайт. Сколько у нас сейчас оперативки? Может база данных такое в кеш поместить? По-моему на любом задрипаном компе.
Таким образом вообще нагрузки нет.
Во-вторых, у вас же работа идет в памяти, а база - это при загрузке/сохранении, то есть вообще довольно редко.
Смотрите не количество строк, а количество операций в секунду и их сложность.
У нас был веб-проект, на 100 тысяч онлайн. mysql вполне справлялся, учитывая что почти вся активность шла через постоянные запросы в базу. Сервер был минимальный обычный, 4 гб оперативки
Простой
Средний
Средний