Шаблон проектирования для разработки игр

Я разрабатываю игру, которая в настоящее время использует контракт GameFactory для создания экземпляров контракта Game. Шаблон Factory позволит любому количеству игроков играть в свою собственную одиночную игру, а игровые данные будут храниться в отдельных экземплярах Game.

Однако в идеале мне нужны контракты Game для взаимодействия с контрактами GameFactory для обновления глобальных рекордов и статистики обо всех играх, в которые в данный момент играют.

Что было бы хорошим способом добиться этого? Существуют ли какие-либо существующие примеры шаблонов для подобных децентрализованных игр?

Рассматривали ли вы возможность хранения всех ваших данных в одном смарт-контракте? Объектно-ориентированные шаблоны часто плохо переводятся в контракты Solidity. Обычно вы не должны думать о контрактах так, как вы думаете, например, о классах Java.
У меня есть около 20 переменных, включая массивы и сопоставления, которые мне нужно отслеживать для каждого «экземпляра» игры. Вместо этого я должен создать большую структуру всех этих переменных и создать сопоставление с адресом игрока и структурой игровых данных? Затем получать доступ к этому сопоставлению каждый раз, когда мне нужно вызывать функцию для обновления?
Чтобы противоречить @JesseBusman, с точки зрения аудитора безопасности я предпочитаю фабрики и отдельные экземпляры контрактов. По моему опыту, эту модель легче реализовать правильно, чем ту, в которой каждый вызов функции принимает идентификатор и должен выполнять более сложную проверку разрешений.
Что касается исходного вопроса, я не понимаю проблемы. Просто вызовите Game в GameFactory. GameFactory должна хранить сопоставление игр, чтобы знать, что полученные данные действительны (поступают из развернутого контракта).

Ответы (1)

Расположение ступицы и спицы имеет преимущества, как и монолитный контракт.

Концентратор и спица

  • Более простая внутренняя структура, возможно, более читаемая
  • При желании можно использовать путь «последовательного обновления».

Монолитный

  • Инициализация нескольких переменных обходится значительно дешевле, чем развертывание нового контракта для каждой игры.

Работа на основе Hub and Spoke, естественно, приводит к некоторым общим проблемам. Как вы упомянули, вероятно, спицам необходимо обновить глобальные переменные в концентраторе, а концентратору необходимо ограничить доступ к определенным функциям, чтобы это было разрешено только споку, и т. д.

Мои исследования привели меня к созданию обобщенных контрактов, примерно:

contract Hub is Deployer { ...

contract Spoke is Deployed { ...

Учтите, что Deployer отслеживает развернутые Spokes и выполняет такие действия, как:

modifier onlyDeployed { // only trust contracts made by this Hub

... и Deployed делает такие вещи, как запоминание Хаба, который его породил.

Если вы хотите иметь возможность обновить логику игры, вы можете рассмотреть возможность дальнейшего разделения данных Hub и логики Factory. То есть вы хотите иметь возможность хранить глобальные данные в контракте, который, как ожидается, не изменится, при этом периодически заменяя контракт, который развертывает новые игры.

Самая низкая стоимость газа и самый простой подход — это монолитный контракт с игровыми данными, объединенными в структуры, и без возможности обновления.

Надеюсь, поможет.

Шаблон проектирования для разработки игр
СпросиСетьПолитика конфиденциальности1y, 0v