Самый эффективный способ отслеживания улучшений навыков игрока

Question

До сих пор я исследовал два различных способа постоянного отслеживания навыков атрибутов игрока в игре. Они в основном концептуальные, за исключением варианта работы с потоками, для которого я нашел / нашел пример.

Корпус:

Индивидуальная разработка веб-игры. Геополитический симулятор, но с небольшим поворотом по сравнению с другими, о котором я не буду рассказывать.

Я использую комбинацию Flask и SQLAlchemy, для которой я написал маршруты и имею шаблоны, динамически расширяющиеся в базу.

В настоящее время он работает локально в режиме разработки с намерением поместить его позади WSGI и обратного прокси-сервера, такого как Nginx, в Linux на основе облака vm.

О механике атрибутов игрока - игрок отправит запрос на публикацию, в котором будет указано несколько бит информации. Сначала мы хотим узнать, какой навык, интеллект, выносливость и т. Д. В следующий раз нам нужно знать, какого игрока, но все это будет сгенерировано автоматически, мы можем использовать Flask-LoginManager, чтобы получить текущего пользователя с нашим отличным декоратором user_loader и функцией. Мы можем использовать предоставленный им идентификатор пользователя, чтобы запросить остальную часть, а именно, какой уровень у игрока. Мы можем указать математику, используемую для определения увеличения времени ожидания позже в секундах.

Опции;

Вариант 1:

По предложению моего коллеги. Разрешить базе данных управлять временем навыков. Когда пользователь отправит форму, мы создадим новую таблицу для хранения информации об обновлении навыка. Мы принимаем к сведению, когда пользователь отправил форму, а также умножаем текущий уровень навыков на X раз и помещаем обе части данных в базу данных. Затем мы создаем новый процесс, который управляет постоянной проверкой этой таблицы. Используя timedelta, мы можем проверить, равно ли время, прошедшее с момента отправки формы, равно или больше времени, которое игрок должен ждать до завершения обновления.

Вариант 2:

Импортируйте потоки и создайте класс, который ожидает ту же информацию, что и abovr, предоставленную в init, а затем просто используйте time.sleep в течение X промежутка времени, затем запустите обновление и уничтожите поток, когда он закончится.

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

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

Я открыт для добавления еще одной библиотеки в пакет, но я бы действительно не хотел.

Answer 1

Я немного дополню свой комментарий:

С точки зрения масштабируемости:

• Что если процессы обновления станут очень длинными? Часы или дни?
• Что делать, если у вас много пользователей
• Что если люди отключаются и подключаются к сеансам в разное время?

Надеюсь, очевидно, что вы не можете обеспечить надежный процесс с опцией 2. Потоки и ожидание создадут непрерывную и потенциально ограничивающую нагрузку на сервер, и в случае сбоя сервера все эти потоки могут быть потеряны.

С точки зрения надежности:

С другой стороны, если вы записываете всю информацию в базу данных, у вас есть возможность перекрестной проверки состояний любых элементов и выполнения действий по обновлению / понижению, если это необходимо для какой-либо формы планировщика задач. Это позволяет вам гарантировать, что состояния персонажа всегда соответствуют тому, что вы ожидаете. Вам нужен только один процесс для периодического сканирования БД и выполнения действий со всеми открытыми строками, помеченными для обновления.

Вы можете, если хотите, также вообще избежать глобального планировщика задач. Когда пользователь выполняет действие на сайте, небольшая задача может выполняться в фоновом режиме (в качестве своего рода декоратора), который проверяет состояние обновления и, если настало время, выполняет действия с БД, в противном случае просто проходит. Но пользователь должен быть активно в сеансе, чтобы убедиться, что это происходит, в отличие от запланированной задачи выше.