Найти - Пользователи
Полная версия: Как правильно построить архитектуру модели?
Начало » Python для экспертов » Как правильно построить архитектуру модели?
1
in
Пишу игру. Архитектура проекта такова. Есть какой-то основной герой на выбор. У каждого героя есть своя уникальная книга юнитов и заклинаний. Так же есть одна общая для всех книга. В каждой книге допустим по 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
Решил поступить следующим образом. Оставляю Карты и Книги как есть (библиотеками возможных юнитов и заклинаний). При инициализации создаю коллекцию карт игрока. Вместо карт она хранит список UserCard которвый в свою очередь хранит ссылку на оригинальную карту (свою модель) а также те возможные свойства, которые касаются отдельного игрока (количество одинаковых карт, доступна ли карта сразу или ее необходимо крафтить и.т.п) Также добавил класс маску, которая описывет каким образом конфигурирется коллекция при открытии новых книг. С помощью маски в коллекцию добавляются UserCard на все карты книги, но в свойствах описываются уже их конректные настройки.
scopichol
доступна ли карта сразу или ее необходимо крафтить
Зачем это хранить сразу в коллекции игрока?
по смыслу “коллекция игрока” это то что у него уже есть, а то что может быть - находится в библиотеке.
И скорее всего доступность это характеристика карты из библиотеки. Часть карт доступна сразу остальные по какому либо условию и подобные условия могут быть функцией или отдельной моделью

А вообще архитектура приложения( не модели ) какая то мутная получилась.
Лучше сделать простой, а потом для повышения производительности добавлять костыли
in
scopichol
“доступна ли карта сразу или ее необходимо крафтить”
Зачем это хранить сразу в коллекции игрока?

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

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

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

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

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

Например: колличество и если карта еще не скрафчена то отсутствие экземпляра отношения.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB