Войти
ПрограммированиеФорумОбщее

Как хранить свойства объектов на карте? (3 стр)

Страницы: 1 2 3
#30
15:45, 6 дек. 2016

Итемтип - ид типа предмета например 1- бутылка водки 2- серп
Для сервера своя БД для них служебная. Для клиента файл данных с соответствия ми. Например моделька иконка и название.
Placenent маска куда оно надето, 0 если снято.
Count - число
Enc - служебные параметры улучшения и модификации
Например в электронной карте у меня в энк1+энк2 хранится баланс на ней :)


#31
16:11, 6 дек. 2016

Это, типа, экзамен? А если отвечу правильно, получу сертификат?

#32
16:43, 6 дек. 2016

Mira
Ладно, я тебя понял, ты просто запихал в одну таблицу сразу кучу информации. :) Ты ведь догадываешься, что таблица с предметами игроков будет, скорее всего, самой большой таблицей в игре? Имею ввиду в плане наполнения. Куча игроков у которых куча предметов ...

Я предлагаю тоже самое, только с более детальным разделением. "Экипирование предмета" - это, по сути, отдельная функция, не относящаяся непосредственно к предмету. Поэтому она выделена в отдельную таблицу. Это даст более гибкую систему.

iLoled
Не, мы тут мморпг делаем.

Mira, Мужик
В общем, с инвентарём разобрались, будет таблица:

CharactersItems {
  player; // ID Игрока.
  item;// ID Предмета.
  count; // Количество.
}

Думаю с этим понятно, как выделить простые сущности. Дальше давай поинтереснее, у нас будет список друзей в игре. Друзья - это другие персонажи. Каждый персонаж имеет свой список друзей, куда может добавлять и удалять других персонажей в игре. Как будет выглядеть структура списка друзей в бд?

#33
17:05, 6 дек. 2016

Tails
это и есть самая большая таблица на серверах ммо
Tails
> iLoled
> Не, мы тут мморпг делаем.
у меня эта часть сделана давно и мне не интересна. я холиварил на тему упорядоченного хранения , с минимумом левых сущностей и кучи лишних связей

#34
17:14, 6 дек. 2016

Ладно, в конце концов, мы же пытаемся помочь разобраться Мужику. Скажи что нибудь, куда нам двигаться дальше? А то я уже немного устал писать, хотя мы ещё даже не начинали программировать.

#35
17:18, 6 дек. 2016

мужик, по моему, давно махнул рукой и ушел.
и я тоже ушел делать "ММО" =)

#36
23:14, 6 дек. 2016

а). Сериализовать всегда как массив произвольной длины, в формате
UID, тип_свойства1, значение1, ... тип_свойстваN, значение N, 0
, где пустые/дефолтные свойства пропускаются.
например, тип свойства = ячейка штанов, значение = UID штанов.

Таблица в базе (если мускуль, например) навсегда имеет формат типа `uid` INT, `param_json` MEDIUMTEXT. При записи/чтении запаковывается/распаковывается в строку, с парсингом и проверкой совместимости версий.


Как в памяти хранить - как душе угодно. Если каждый игрок занимает килобайт, и их миллион, то это - ах, трагедия - целый гиг оперативы.
Не смешно, блин. Можно тупо держать всё в памяти сервака а на диск сливать снапшоты типа точек восстановления, да и то раз в полчаса или в фоновом режиме.
Нахрена вам БД если вы можете хранить всё в нормальных объектах через простейшую фабрику классов? ООП иль не ООП, вот в чём вопрос.
Можно вообще тупо снапшоты в текстовый файл сливать, без никаких БД. Ну, или в бинарный. Что совой об пень, что пнём об сову.


Узкое место ведь - передача всей этой байды клиенту, или как?
А если передача клиенту, то каким боком тут БД? Тут нужны оптимизированные механизмы сериализации для протаскивания верблюда через сетевое соединение.

#37
23:35, 6 дек. 2016

Cheb
у него по моему проблема не с сетью и не с бд (которая таки нужна в промышленном варианте сервера). проблема в коде, как все это держать в памяти и как связывать чтоб при усложнении не заплюхаться. про бд и сеть это мы уже оффтопим

#38
2:11, 7 дек. 2016

Мужик
> Это нормально или пиздец?
говнокод

#39
2:18, 7 дек. 2016

Mira
Ты прав. Но я уже от нескольких людей получил ответ который мне нужен был, и в рамках темы пришли идеи как в моём варианте это лучше организовать. Спасибо за помощь.
А вашу дисскуссию с Tails я слушаю в целях общего развития, у меня мультиплеер не предполагает больше двух-трёх десятков человек, и то это самые крайние цифры.

#40
10:32, 7 дек. 2016

Мужик
Я хотел показать, что перед тем как начинать программирование, необходимо составить структуру всех данных. Потом её легко будет и в бд записать, и по сети передать и в озу держать. Заметте, что все связи содержаться в нашей структуре, в коде у вас не будет ни одного перечисления или классов, содержащих конкретные данные. Код будет только обрабатывать структуру. При добавлений новых предметов, слотов экипировки или объектов, мы не создаём новые классы, мы заполняем структуру.

#41
10:39, 7 дек. 2016

>в коде у вас не будет ни одного перечисления или классов, содержащих конкретные данные.
В коде могут быть объявлены константы (или глобальные переменные, инициализируемые из конфига) типа BASE_SWORD_DAMAGE = 15 и BROADSWORD_DAMAGE_MULTIPLIER = 1.4
А в базе (или где у вас там перечисляются конкретные мечи) хранится не урон, а поправочный множитель.
Это чтобы с балансом не мудохаться, редактируя 100500 записей при каждой поправке.

#42
10:57, 7 дек. 2016

Cheb,
Проще, когда всё хранится в одном месте. Если есть трудности с заполнением, напишите редактор, сделайте админку.

#43
21:52, 7 дек. 2016

Вариант сэмплированого мира (например, тайлы)..

const int  one_obj_holder_last = 50; // все варианты кубиков в мире
t_one_obj  one_obj_holder[ one_obj_holder_last +1];

bool one_obj_holder__load( filename)
{
  // загрузить сэмплы кубиков
}

const int
kub_iron = 1,
kub_sand = 2,
kub_table = 31,

kub_empty = 0;

t_mir
{
t_kub  k3m[10][10][10];
};
t_mir  mir;

bool mir__load( filename)
{
  // прочитать тысячу строк - в каждой, указан номерок кубика
  for
  {
    nom_kub = read_line( f); // kub_empty, kub_iron, kub_sand ...

    mir.k3m[ очередной кубик].one_obj_uniq = 0; // !!!
    mir.k3m[ очередной кубик].one_obj_nom = nom_kub;
  }
}

-----

Ниже, вариант использования one_obj_holder для представления игроков,
которые могут передвигаться дискретно, из одной клетки мира в другую,
и не могут занимать клетку, занятую другим игроком.

// t_kub::x = kub_table;  вместо  t_kub::one_obj_nom = kub_table;
// Тоесть, сэмплированый мир, но номер сэмпла храним в простом свойстве,
// а линк-свойство - для связи с информацией про игрока _на_этой_клетке.


const int one_obj_holder_last = 30; // максимум игроков на одной карте.
t_one_obj  one_obj_holder[ one_obj_holder_last +1];

bool one_obj_holder__add_player( ник_игрока, x, y, z)
{
  // Проверить клетку, учитывая стартовое обноление в mir__load
  if( mir.k3m[ x y z].one_obj_uniq )
    return 0; // занято

  // Получить первую пустышку опознавая  t_one_obj::my_type as zero
  t_one_obj* p = get_first_empty();
  if( ! p )
    return 0;

  p->my_type = 1; // можно назначать внутри core__get_info
  p->my_obj_uniq__get_next_uniq();
  // p->my_obj_nom // это заполнить один раз, на старте проги

  // Назначить (прочитать из базы) исходные свойства игрока
  p->core__get_info( db, ник_игрока);

  // Поставить-привязать игрока в нужную клетку
  mir.k3m[ x y z].one_obj_uniq = p->my_obj_uniq;
  mir.k3m[ x y z].one_obj_nom = p->my_obj_nom;
  // делать подобное, когда игрок переходит в другую клетку,
  // и обнолять эти свойства в старой клетке.

}

Страницы: 1 2 3
ПрограммированиеФорумОбщее

Тема в архиве.