Уведомления

Группа в Telegram: @pythonsu

#1 Авг. 3, 2014 21:39:55

in
Зарегистрирован: 2013-09-11
Сообщения: 68
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

Пишу игру. Архитектура проекта такова. Есть какой-то основной герой на выбор. У каждого героя есть своя уникальная книга юнитов и заклинаний. Так же есть одна общая для всех книга. В каждой книге допустим по 20 уникальных карт (либо юнитов либо заклинаний). В начале игры игрок может составить себе уникальный отряд из 20 юнитов либо заклинаний. Выбрать юниты или заклинания из той или иной книги.
Пока кажется что можно все описать имея класс Карты (юнит либо заклинания) и Книги которая содержит в себе простой список карт. Проблема в том, что не все карты могут быть изначально открыты. То еть у одного игрока эти юниты уже развиты и доступны для сборки в отряд у другого еще нет. Также каждой карты может быть по три экземпляра, соответсвенно у одного игрока может быть в коллекции все три экземпляра этой карты а у другого не одного. Как поступать в этом случае? Создавать для каждого игрока отдельные экземпляры Книг и Карт или можно как-то оставить Книги и Карты как библиотеки, а для игрока создавать модель его конкретного набора? Не могу пока придумать как сохранить единственные экземпляры книг и карт и не плодить тысячи одинаковых инстансов, у которых будет отличаться только foreignkey на юзера и их доступное количество дляя конкретного игрока, тогда как все остальные свойства будут идентичны.

Пока модель условно такая:

class Hero (model:Model):
       eptitude = model.IntegerField ()
class Book (model.Model):
       hero = model.ManyToManyField (Hero)	
	
class Card (model.Model):
       attack = model.IntegerField ()
       health = model.IntegerField ()
       book = model.ForeignKey (Book)

И создан конкретный экземпляр книги с пятью конкретными картами со своими характеристиками аттаки и здоровья, для одного отдельного Hero. Если бы всех карт у игрока было всегда по одной, и все они были бы октрыты сразу, то можно было бы создать класс Collection который представлял бы собой еще один список карт надерганных игроком из разных книг.

class Collection (model.Model):
       cards = model.ManyToManyField (Card)
Но проблема в том, что у разных игроков может быть досупно разное количество карт. То есть одной и той же карты из книги у одного игрока может быть три а у другого ни одной. Когда игрок регистрируется и выбирает Hero создается отдельный экземпляр книги в которой доступно для игры только две карты из пяти. Обоих карт по два экземпляра, а остальные карты ему необходимо крафтить. То есть они в принципе ему доступны, так как он выбрал персонажа особого типа, но только после того как он их разовьет.


Отредактировано in (Авг. 3, 2014 22:21:48)

Офлайн

#2 Авг. 4, 2014 12:16:40

in
Зарегистрирован: 2013-09-11
Сообщения: 68
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

Решил поступить следующим образом. Оставляю Карты и Книги как есть (библиотеками возможных юнитов и заклинаний). При инициализации создаю коллекцию карт игрока. Вместо карт она хранит список UserCard которвый в свою очередь хранит ссылку на оригинальную карту (свою модель) а также те возможные свойства, которые касаются отдельного игрока (количество одинаковых карт, доступна ли карта сразу или ее необходимо крафтить и.т.п) Также добавил класс маску, которая описывет каким образом конфигурирется коллекция при открытии новых книг. С помощью маски в коллекцию добавляются UserCard на все карты книги, но в свойствах описываются уже их конректные настройки.

Офлайн

#3 Авг. 4, 2014 12:46:20

scopichol
Зарегистрирован: 2014-08-04
Сообщения: 16
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

доступна ли карта сразу или ее необходимо крафтить
Зачем это хранить сразу в коллекции игрока?
по смыслу “коллекция игрока” это то что у него уже есть, а то что может быть - находится в библиотеке.
И скорее всего доступность это характеристика карты из библиотеки. Часть карт доступна сразу остальные по какому либо условию и подобные условия могут быть функцией или отдельной моделью

А вообще архитектура приложения( не модели ) какая то мутная получилась.
Лучше сделать простой, а потом для повышения производительности добавлять костыли

Офлайн

#4 Авг. 5, 2014 02:55:33

in
Зарегистрирован: 2013-09-11
Сообщения: 68
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

scopichol
“доступна ли карта сразу или ее необходимо крафтить”
Зачем это хранить сразу в коллекции игрока?

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

Просто карта это именно игровая карта со своими игровыми характеристиками. Я в админке создаю новую карту и она банально описывает ее параметры. Допустим создаю юнит “курица” с атакой 1 и здоровьем 1. И это всего лишь один единственный экземпляр для всех без исключения игроков. Если же запихивать в нее свойства amount (количество доступных экземпляров для отдельного игрока), и флаг о том скрафтил ее игрок или еше не успел то получится что для 10 000 игроков придется создать 10 000 одинаковых куриц. И еще по столько же других юнитов доступных каждому игроку.

Отредактировано in (Авг. 5, 2014 03:04:37)

Офлайн

#5 Авг. 5, 2014 06:46:59

Shaman
Зарегистрирован: 2013-03-15
Сообщения: 1369
Репутация: +  88  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

in
получится что для 10 000 игроков придется создать 10 000 одинаковых куриц.
И что? Это проблема? У конкретного игрока есть конкретная курица - всё естественно.

Офлайн

#6 Авг. 5, 2014 15:16:24

in
Зарегистрирован: 2013-09-11
Сообщения: 68
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

Shaman
И что? Это проблема? У конкретного игрока есть конкретная курица - всё естественно.

Да если потребуется внести изменения в характеристики карты, придется менять параментры не в одной карте а в 10 тысячах.

Офлайн

#7 Авг. 5, 2014 15:32:20

Shaman
Зарегистрирован: 2013-03-15
Сообщения: 1369
Репутация: +  88  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

in
Да если потребуется внести изменения в характеристики карты, придется менять параментры не в одной карте а в 10 тысячах.
Хорошо проектируйте систему и потребность в модификации структуры БД будет возникать редко. Само обновление БД распространено повсеместно и обычно проходит без эксцессов.
Если будете отслеживать классы и экземпляры с идентичными свойствами, усложните систему и получите проблем ещё больше чем видите при нынешнем подходе.

Офлайн

#8 Авг. 7, 2014 14:36:17

scopichol
Зарегистрирован: 2014-08-04
Сообщения: 16
Репутация: +  0  -
Профиль   Отправить e-mail  

Как правильно построить архитектуру модели?

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

Зачем так изощренно
Просто реализуйте отношение многие ко многим посредством модели (параметр through)
И в этой модели будут только поля относящиеся именно к своствам этого отношения

Например: колличество и если карта еще не скрафчена то отсутствие экземпляра отношения.

Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version