Tiendil

Не хочу увеличивать и без того большой объём ответа. Лучше воспринимать сообщение не как массив, а как кортеж, тогда всё ок.

Спасибо за ответ, но в таком случае выглядит скорее как полумера, ведь в некоторых местах (например quests) всё вроде структуркой сделано (хотя actors всё-таки тем же кортежем) )
Тут, полагаю надо более основательно подходить к вопросу необходимости разделения возвращаемых данных.(

Zanleo

Предложение
“hero_info”.“messages”:[ // сообщения из журнала
[ // запись в задании
<timestamp>, // timestamp создания сообщения
“строка”, // текстовое описание времени в игре
“строка”, // текст
]
],

Возможно ли сделать более логическую структуру типа?:
“hero_info”.“messages”:[ // сообщения из журнала
{ // запись в задании
“time_stamp”: <timestamp>, // timestamp создания сообщения
“description”: “строка”, // текстовое описание времени в игре
“text”: “строка”, // текст
}
],

Причина:
1) Само сообщение не является массивом, потому что имеет разнотипные (по сути и типу) поля.
2) Логичнее представлять messages, как массив объектов типа message(условное название), где message = {“time_stamp”:&lt;&gt;, “description”: &lt;&gt;, “text”: &lt;&gt;,}

Аналогично с diary

Сообщение изменено 15.03.2014 2:45

Zanleo
Где ты нашел hero_info?
Я конечно понимаю, что это выглядит лучше:
Чем
Но особой выгоды от этого нет, не так ли?

Не забываем что перебор асоц. массива это O(n) на поиск ключа, перебор циклом по индексу это тоже O(n), с точки зрения производительности все равно, но при обращении вида arr[1] затраты ресурсов меньше, чем arr['name'], ибо асоц. доступ это поиск совпадения ключа перебором, доступ по индексу это прямой доступ.

Дарклидер

Где ты нашел hero_info?
Но особой выгоды от этого нет, не так ли?

<hero_info> - это как описано в документации), конечно же речь о "hero" в "account".
Выгоды нет (кроме, как описано выше - обращение по индексу всё-таки быстрее) и восприятия принимаемых данных.
Просто как писал выше
Zanleo

выглядит скорее как полумера

Примеры:
1) habits - каждая черта состоит из 2-х элементов raw и verbose. Но они сделаны всё-таки структурой, а не кортежем.
2) line - сделана структурой (хотя намного выгоднее было бы сделать массив, но потеряется читаемость)
3) equipment и bag так и вообще dictionary (хотя можно было бы опять же воспользоваться кортежем и сэкономить на передаваемых данных).

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

Zanleo

Дарклидер

Где ты нашел hero_info?
Но особой выгоды от этого нет, не так ли?

<hero_info> - это как описано в документации), конечно же речь о “hero” в “account”.
Выгоды нет (кроме, как описано выше - обращение по индексу всё-таки быстрее) и восприятия принимаемых данных.
Просто как писал выше
Zanleo

выглядит скорее как полумера

Примеры:
1) habits - каждая черта состоит из 2-х элементов raw и verbose. Но они сделаны всё-таки структурой, а не кортежем.
2) line - сделана структурой (хотя намного выгоднее было бы сделать массив, но потеряется читаемость)
3) equipment и bag так и вообще dictionary (хотя можно было бы опять же воспользоваться кортежем и сэкономить на передаваемых данных).

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

Быстрее как раз обращение к массиву по индексу, не по ключу.
Приведи пример кортежа, ибо я тебя не понял.

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

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

Текущий данных для начала хватает, их легко можно парсить со страницы, благо статистика и мониторинг область проф деятельности и опыт большой :)

Tiendil

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

Если подробнее, то хочу собирать статистику того, что происходит в мире (города, советники, население)

Похвальное начинание. У меня на это времени нет, а красивые графики все любят смотреть :-)

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

P.S. Сейчас API методов для получения информации о городах и прочем нет. Если что-то конкретное надо — пиши, постраюсь скорректировать планы по реализации.

Как нет, а http://the-tale.org/game/map/cell-info?x=42&y=16?

введите авторизацию для приложения, не многие хотят вводить свой логин пароль