PDA

Просмотр полной версии : Организация серверного сохранения и загрузки юзерами уровней игры.


Astraport
25.06.2012, 10:15
Хочется сделать в игре такую фичу - юзер может сам создать уровень расположив разные игровые объекты в игровом мире, придав им нужные свойства, затем расшаривает сохраняя на сервере и другие юзеры могут открыть любой из этих уровней и начать играть. Возник ряд, пока теоретических, проблем. Это скорее мысли вслух, чтобы все упорядочить и получить советы как лучше все организовать.

1. Используются мобильные платформы. Если для Андроида все ОК. То не будет ли проблем с безопасностью для iOS при загрузке файлов приложением из сети?

2. Данные уровня на сервере выглядит как таблица в mySQL. То есть, если таких уровней насохраняют 10000, то и таблиц будет столько же. Как решить пока не знаю. Дело в том, что сейчас юзер сохранив уровень, получает отдельную таблицу в SQLite в которой прописаны в каждой из записей объекты с их свойствами (x, y, rotation, type, power, armor и т. п.), скриншот уровня и, если он добавлял свои картинки, то эти картинки с уникальными именами. Сохраняя уровень на сервер, все это хозяйство отправляется туда же. Уровень автоматически визуально оформляется на сайте как новость - название, описание, скриншот, рейтинги, комменты и т. п. Вот как лучше хранить подобные данные в БД? Чтобы не в виде отдельных таблиц, а сделать одну ключевую таблицу уровней с ссылками на таблицу элементов? Не будет ли бардака?

3. Теперь о размерах экранов. Уровень созданный в телефоне могут открыть в планшетнике, где другие размеры экрана и пропорции. Естественно, используя абсолютные координаты объектов, все будет криво. Вижу два пути. Или все координаты сохранять в %% и потом так же относительно размещать при открытии уровня. Или, при сохранении, передавать разрешение экрана сохраняющего юзера, а при открытии рассчитывать различия и на основе полученных коэффициентов, расставлять объекты максимально заполняя пространство. От различных пропорций экрана это не спасет, но все же лучше, чем игровое пространство на пол экрана.

4. Ну и главное. Как открывать уровень. Было бы круто иметь в новости кнопку "Открыть" при нажатии которой запускалось бы приложение и автоматически открывался выбранный уровень. Видимо это фантастика. Выход вижу один - создать в приложении, на основе данных с сайта аналог новостной ленты и по клику подгружать и открывать выбранный уровень. Хотя есть и ещё одно не простое решение - сделать в приложении StageWebView. Научить сайт показывать кнопку "Открыть" только при открытии из приложения. По клику на кнопку, запускать JS, который возьмет все нужные данные и передаст через мост StageWebView в приложение.

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

fish_r
25.06.2012, 11:23
2. Данные уровня на сервере выглядит как таблица в mySQL. То есть, если таких уровней насохраняют 10000, то и таблиц будет столько же. Как решить пока не знаю. Дело в том, что сейчас юзер сохранив уровень, получает отдельную таблицу в SQLite в которой прописаны в каждой из записей объекты с их свойствами (x, y, rotation, type, power, armor и т. п.), скриншот уровня и, если он добавлял свои картинки, то эти картинки с уникальными именами. Сохраняя уровень на сервер, все это хозяйство отправляется туда же. Уровень автоматически визуально оформляется на сайте как новость - название, описание, скриншот, рейтинги, комменты и т. п. Вот как лучше хранить подобные данные в БД? Чтобы не в виде отдельных таблиц, а сделать одну ключевую таблицу уровней с ссылками на таблицу элементов? Не будет ли бардака?


Может лучше, перед отправкой на сервер делать объект с данными (ДО) и далее, например сериализовав, хранить его в строке.... Уровень - таблица, имхо, как то расточительно.

Astraport
25.06.2012, 11:37
например сериализовав, хранить его в строке
Я так когда-то делал для сохранения параметров юзеров. Но тогда получалась строка 200-300 знаков. Сейчас, если сериализовать все объекты с их свойствами, которых может быть и полсотни, то получится строка в несколько тысяч знаков. Боюсь допустить ошибку, да и отлаживать сложнее.

А чем не нравится вариант с двумя таблицами? В одной храним все полученные объекты от всех юзеров, но каждая запись имеет ссылку (уникальный id) на другую таблицу где хранятся данные по уровню (дата создания, название, описание, рейтинг, комменты и т. п.). Вот только опять же первая таблица может вырасти до 10 - 50 тыс. записей. Насколько долго будет происходить вся эта выборка объектов по заданному уровню не понятно.

fish_r
25.06.2012, 12:13
А чем не нравится вариант с двумя таблицами? В одной храним все полученные объекты от всех юзеров, но каждая запись имеет ссылку (уникальный id) на другую таблицу где хранятся данные по уровню (дата создания, название, описание, рейтинг, комменты и т. п.). Вот только опять же первая таблица может вырасти до 10 - 50 тыс. записей. Насколько долго будет происходить вся эта выборка объектов по заданному уровню не понятно.

Если храним объекты в отдельной ( даже с их дефолтными свойствами ) таблице, а в таблице описывающей конкретные уровни храним ид объектов ( ссылающихся на конкретные записи в таблице с объектами) и измененные их св-ва, то будет норм. Никакой путаницы не получится.
Далее через индексы сопоставляем данные таблиц - ид объектов, детали юзеровских уровней, сопровождающую информацию, комменты, рейтинги и т.д. Это нормальная практика работы с БД. 50 тыс. записей - имеется в виду "полей"? Если именно записей ( строк ) то для серверной БД это ерунда.