Как реализовать высокие результаты в Интернете в Google App Engine - PullRequest
10 голосов
/ 04 марта 2009

Я хочу внедрить высокие результаты в Интернете для своей игры. И дать обратную связь игрокам, какое место у них есть (не только топ100 или что-то подобное) В обычном SQL это будет выглядеть так:

ВЫБЕРИТЕ СЧЕТЧИК (*) ИЗ СЧЕТОВ ГДЕ очков>: newUsersPoints

и GQL имеют что-то похожее

db.GqlQuery («ВЫБЕРИТЕ * ОТ ОЦЕНКИ, ГДЕ очков>: 1», newUsersPoints) .count ()

но поскольку count () ограничен только 1000, в моем случае это будет не очень полезно. У вас есть идеи, как это реализовать?

У меня есть два

Во-первых:

  1. Использование идеи счетчиков шардеров (http://code.google.com/intl/pl/appengine/articles/sharding_counters.html) Создайте новую «таблицу», в которой будет храниться количество баллов в некотором диапазоне (от_пунктов до_пунктов)

  2. Суммировать все счетчики из приведенной выше таблицы, где range.to_points

  3. Найдите, сколько баллов больше, чем баллов в диапазоне, где новый балл db.GqlQuery («ВЫБЕРИТЕ * ИЗ СЧЕТА ГДЕ очков>: 1 И очков> =: 2 И очков <: 3», newUsersPoints, range.from_points, range.to_points) .count () + sumfrom2 </p>

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

  5. Разделить диапазоны, счетчик которых больше 1000 (или 999), чтобы 3. не достигал предела

  6. Добавить новый счет в таблицу результатов

Что довольно сложно и подвержено ошибкам. Мы могли бы увеличить некоторый диапазон и тайм-аут, прежде чем добавить счет. (не транзакционный)

Вторая идея:

Время от времени (один раз в день?) Сортируйте все оценки по точкам и назначайте им новые позиции (сценарий может использовать тайм-аут, поэтому мы должны делать это кусками)

Чтобы узнать, в каком месте новый счет, мы просто делаем

db.GqlQuery («ВЫБЕРИТЕ * ИЗ СЧЕТА ГДЕ очков>: 1 ПРЕДЕЛ 1», newUsersPoints) .get (). Precalculated_position + 1

Есть еще идеи?

Ответы [ 2 ]

5 голосов
/ 10 июня 2009

Я реализовал Ranker в нескольких приложениях GAE. Это приложения Facebook, в которых играют от тысячи до сотен тысяч человек. Это работает хорошо, но для моих целей у него есть один большой недостаток: вам нужно заранее объявить окончательный диапазон, в который попадут баллы участника. Так что это плохо по двум причинам:

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

  2. в начале соревнования, когда все сгруппированы около нуля, древовидная структура, используемая ranker.py, неэффективна. дерево идет очень глубоко и почти не использует ширину.

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

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

4 голосов
/ 04 марта 2009

Эта ветка в группе google-appengine , вероятно, будет интересна. Также похоже, что есть библиотека, ranklist , специально для этого.

По сути, похоже, что они сделали что-то похожее на осколки.

...