У меня, в тестовых приложениях, данный параметр (auth_key) доступен. Но для начала надо активировать свое приложение, система платежей не обязательна (вкладка «настройки», параметр «приложение включено и видно всем»).
Тогда я действительно неправильно понял. Собственно у меня работа организованна похожим образом. Например предметы из инвентаря представляют из себя коллекцию backbone.js, для перетаскивания предметов используется draggable/droppable из jquery-ui. При перетаскивании предмета на клиенте проверяются доступные слоты, которые подсвечиваются. После того, как игрок опустит предмет в определенный слот, формируется запрос к сервер. Сервер производит необходимые вычисления и возвращает обновленные характеристики игрока (если необходимо, например мы одели предметв экипировку), либо код ответа 200 (если мы просто переместили предмет в соседний слот инвентаря).
Мне кажется у нас дебат немного о другом идет :) Я лишь склоняюсь к тому, что игровую механику бессмысленно рассчитывать на клиенте. Это накладно и не безопасно. Давайте рассмотрим простой случай: у нас происходит поединок между 2 игроками. При загрузке страницы мы имеем данные об обоих игроках.
В вашем случае после атаки одного игрока другим мы рассчитываем полученный урон на клиенте, рассчитываем обновленный уровень жизни атакуемого игрока и отправляем его на сервер, чтобы обновить базу данных. По крайней мере я так понял вашу позицию.
Моя позиция такова, что игрок при атаке производит действие, отправляя на сервер запрос (пусть это будет POST /attack/userID). Сервер ищет игрока с ID равным userID, рассчитывает наносимый урон и обновляет параметры обоих игроков, после чего отправляет обратно обновленные данные обоих игроков в формате json. Ну пусть даже он отправляет лишь изменившиеся за запрос данные, сути это не меняет :) Простите, если не так понял ваши доводы.
Делал браузерную одностраничную RPG. Могу с уверенностью сказать, что даже банальное действие «одеть предмет из инвентаря в экипировку» приводит к довольно сложным вычислениям. Требуется:
1. Проверить наличие предмета с указанным ID в инвентаре игрока;
2. Убедиться в возможности использования данного предмета игроком по уровню/профессии;
3. Обновить запись предмета, чтобы сменить контейнер, в котором он размещен;
4. Пересчитать все характеристики игрока на основе характеристик предмета;
5. Отправить игроку обновленные характеристики;
Пятый пункт можно отменить, если у нас на клиенте есть характеристики предмета, в остальном же в любом случае потребуются проверки.
Вполне возможно, если будет CMS, полностью соответствующая требованиям, но при это не несущая излишней функциональности. По сути, учитывая требования автора вопроса, там потребуется несложный SQL запрос для получения списка портфолио и еще один скрипт с формой для добавления новых портфолио. Если можно редактировать также страницу с информацией о сайте и страницу с контактными данными, то в крайнем случае еще +2 скрипта. Хотя их оба можно вынести в одну сущность, как статичные страницы, с возможностью указать URL для каждой.
Вы хотите использовать для обработки django forms или напишете свой обработчик?
В первом случае вам нужно использовать формсеты, во втором предложенные выше варианты. Если вы отправляете форму с помощью ссылки и onsubmit, то можно добавить скрытое поле, как посоветовал товарищ выше и затем проверять наличие нужной переменной в request.POST, как написано в моем примере.
Если вы импортируете модуль как import socket, то он и не должен содержать метод bind. Если я не ошибаюсь, то модуль bind находится в подмодуле socket:
Да, только при обращении. Этого достаточно, в принципе. Если к объекту обратились, то рассчитываем новые значения, а если никто не обращался, то и грузить систему лишний раз незачем.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
