Браузерная MMO: лучшие практики

Я разрабатываю браузерную онлайн-игру на основе карт Google с бэкэндом Django, и я приближаюсь к тому моменту, когда мне нужно принять решение о том, как реализовать (бэкэнд) синхронизированные события, т. е. увеличение количества владений NPC (например, население города должно расти в зависимости от некоторых переменных — размера города, скорости приложения).

Возможные решения, которые я нашел:

  • Putting the queued actions in a table and processing them along with every request.
    • Problems: huge overhead, harder to implement
  • Using cron or something similar
    • Problem: this is an external tool, and I want as little external tools as possible.

Любые другие решения?


person Gabi Purcaru    schedule 20.07.2010    source источник
comment
Не согласен с тем, что это обман stackoverflow.com/questions/2563742/ Этот вопрос касается реализации запланированных событий, а не связи клиент/сервер   -  person chrisbunney    schedule 21.07.2010


Ответы (2)


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

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

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

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

person Frank Crook    schedule 20.07.2010
comment
+1 за указание на поддержку функций, основанных на времени, которые позволяют вам вычислять значение, когда они вам нужны. - person Chris Marisic; 21.07.2010
comment
Полностью с вами согласен, но. Как я вижу, мой (на основе ajax) пользователь приложения будет обновлять его, скажем, население города всякий раз, когда он загружает информацию о городе (это может делать он или любой другой игрок, возможно, раз в несколько секунд - я здесь речь идет о большом, потому что для меньших размеров я бы не беспокоился о накладных расходах). Дело в том, что я могу пойти на компромисс и обновлять население города каждые 20 минут, что не повредит ни пользователю, ни базе данных. Я не пытаюсь сказать, что вы не правы, мне просто нужно лучше понять это. - person Gabi Purcaru; 21.07.2010
comment
Когда популяция обновляется, Габи, меняется ли скорость роста из-за того, что владелец или кто-то другой сделал что-то? Если это так, вы обновляете базу данных при выполнении этого действия. Но если население будет продолжать расти с такой скоростью, с игроком или без него, тогда вам не нужно обновлять население в базе данных. Он может быть рассчитан на лету, когда вам это нужно. Для статической скорости роста (currentPop = popFromDatabase + (rateOfGrowth * (serverTime - timeOfLastUpdate))). Если он экспоненциальный, вы можете написать рекурсивную функцию или использовать некоторые подходящие математические функции. - person Frank Crook; 21.07.2010
comment
На самом деле население увеличивается с постоянной скоростью, и пользователь может нанимать людей, поэтому оно уменьшается. Идея формулы звучит очень хорошо. Думаю, я воспользуюсь этим. Текущее количество людей будет выглядеть примерно так: rate*timeSinceCityAdded-totalHired. - person Gabi Purcaru; 21.07.2010

Если я правильно понимаю ваш вопрос, вам следует взглянуть на Celery, который представляет собой распределенную очередь задач. http://ask.github.com/celery/

person Mike    schedule 20.07.2010
comment
Это выглядит интересно, я попробую. - person Gabi Purcaru; 21.07.2010